Menú principal

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

miércoles, 17 de julio de 2019

El esquema URL en iOS es vulnerable al Highjacking

El formato o esquema URL en iOS ofrece a los desarrolladores un medio para comunicar apps entre ellas. Pero más allá de la comunicación, con incluir el nombre de la aplicación en la misma URL es también posible abrirla o ejecutarla. Por ejemplo, "facetime://" abrirá FaceTime para realizar por ejemplo, una llamada. Este es sólo uno de los muchos esquemas que existen con este formato para las URL. El abuso de los esquemas URL puede acabar siendo un problema para la seguridad como veremos a continuación.

Apple utiliza un mecanismo de sandbox para la seguridad y privacidad de los datos contenidos en las apps creadas para iOS. Es un sistema bastante seguro pero tiene un pequeño problema: limita demasiado la comunicación entre aplicaciones. Aquí es donde entra el esquema URL. iOS permite un único esquema URL para que dicha aplicación pueda ser llamada por otras, utilizando un sencillo método en el cual se aplica el principio de orden de llegada, es decir, sólo se ejecuta y se registra como auténtica la primera aplicación que utilizó dicho esquema en primer lugar. Aún así, es posible explotar esta vulnerabilidad tal y como explican a fondo en la web de Trend Micro para conseguir un ataque tipo Highjacking (o secuestro)

Figura 1. Aspecto de un token de login robado por la aplicación URLSchemeAttack. Fuente.

Otro de los problemas relacionados con los esquemas URL es que estos pueden ser utilizados para ejecutar aplicaciones, como hemos comentado al principio de este artículo. Es decir, una aplicación maliciosa podría registrar una URL específica, existiendo la posibilidad de que dicho malware se pudiera ejecutar simplemente lanzando dicho esquema URL. Existen muchas aplicaciones de este tipo las cuales intentan reclamar el esquema URL perteneciente a otras aplicaciones conocidas como wechat://, fb://, etc. Esta práctica está muy extendida para conseguir ejecutar pop-ups con publicidad no solicitada.

Figura 2. Algunas aplicaciones maliciosas que intenta sacar provecho de aplicaciones populares. Fuente.

Los esquemas URL pueden ser peligrosos y no se recomiendan para transmitir información sensible o confidencial. Un atacante puede aprovechar la función de "no autenticación" ya que los datos se transfieren independientemente del origen o destino. En su lugar, se recomienda utilizar los llamados universal links, ya que configurando un enlace de este tipo creamos un interfaz de login además de una identificación aleatoria para autenticar el token de inicio recibido. De esta forma es sencillo prevenir un ataque tipo Highjacking además de la reproducción del token de login.

martes, 25 de diciembre de 2018

Una vulnerabilidad en Webkit afecta a las últimas versiones de Safari

Hace unos días se hizo público el código de un exploit para una vulnerabilidad de webkit, el motor de búsqueda que mueve safari y muchas otras aplicaciones y herramientas de macOS, iOS y Linux. El exploit se aprovecha de un error de optimización a la hora de conectar expresiones regulares, lo que puede acabar ofreciendo la posibilidad de ejecutar código arbitrario. Linus Henze, el desarrollador del exploit, ha dicho que la vulnerabilidad ya ha sido parcheada en su origen (Webkit), pero todavía no se ha solucionado en el navegador Safari. Según Henze tanto la versión para iOS como la versión de macOS se encuentran afectadas por el bug, aunque su código solo este diseñado para macOS.

En el caso de iOS, Henze ha dicho que existe un variante de WebKit vulnerable y que afecta directamente a las versiones de iOS que comienzan con la nomenclatura 12.0. En cuanto a macOS la vulnerabilidad también sigue siendo explotable en la versión 10.14 y posteriores. Según Linus los pasos a seguir para obtener un resultado exitoso son muy similares a los que se usaron con el exploit creado hace unos meses por Samuel Grob, al que se le asignó el código CVE-2018-4233 y del que se ha hablado en la Pwn2Own de este año por permitir la ejecución de código remoto en Safari.

“Este es un exploit para las últimas versiones de Safari (como la lanzada el 6 de diciembre de 2018). Como ya se ha arreglado el fallo en WebKit, he decidido hacerlo público” de hecho Henze ha incluido en su GitHub una guía explicado cómo hacer que su exploit funcione correctamente. 

Figura 1: Tweet de Linus Henze.

Aunque el exploit de Henze funcione e incluya instrucciones de uso, un atacante principiante no lo encontraría práctico ya que la protección de Sandbox de Safari podría prevenir que el código se ejecutase correctamente. Para realizar esta prueba de concepto hay que utilizar una serie de exploits conjuntamente con los que se puede evitar la protección de Sandbox explotando otras vulnerabilidades conocidas. En el caso de ser utilizado por un experto este exploit permitiría la ejecución de código arbitrario y a través de él obtener privilegios con los que se podrían bypasear políticas entre ellas la SOP (Same Origin Policy). Esta vulnerabilidad también puede afectar a otros productos basados en JavaScript. Aunque este no sea el caso de Chrome sí podría afectar a algunas aplicaciones basadas en las nuevas versiones de WebKit.

lunes, 19 de febrero de 2018

Una aplicación en una sandbox en Mac puede acceder a información sensible tuya

Las aplicaciones que son ejecutadas en una sandbox en Mac pueden grabar tu pantalla en cualquier instante sin que el usuario lo sepa. En otras palabras, cualquier aplicación de Mac que se ejecute en una sandbox puede tomar capturas de pantalla de tu Mac sin que el usuario lo sepa, puede acceder a cada píxel, incluso si la aplicación Mac está en segundo plano, utilizar software básico de OCR para leer el texto de la pantalla o, incluso, acceder a todos los monitores conectados. Esto ha llevado a la queja de muchos usuarios que ven en esto un grave peligro para la privacidad del usuario.

¿Qué puede ocurrir? Se podría leer la contraseña y las claves de los administradores del equipo. Se podría detectar qué servicios web se utilizan, por ejemplo, qué proveedor de correo electrónico. Se podría leer todos los correos electrónicos y mensajes que se abren en el Mac. Además, se podría permitir al atacante acceder potencialmente al código fuente de un desarrollador, claves API o datos sensibles similares. Realmente, casi cualquier cosa podría ser hecho en lo que a confidencial se refiere. El funcionamiento es sencillo: un desarrollador solo necesita usar CGWindowListCreateImage para generar una captura de la pantalla completa, tal y como se puede ver en la imagen.

Figura 1: Aplicación haciendo uso de estas características

Muchos usuarios se preguntan como protegerse. A día de hoy, no conocemos la forma de protegerse, por lo que esperamos a que Apple indique algo sobre esta situación. La propuesta que investigadores como Felix Krause ha realizado es que en el proceso de subida de apps se verifiquen las autorizaciones de sandbox para acceder a la pantalla u otros recursos. Que el usuario otorgue dicha autorización de algún modo. Sin duda, una noticia interesante en lo que a seguridad en el mundo Apple se refiere. Estaremos atentos a posibles cambios o notificaciones por parte de Apple.

miércoles, 8 de junio de 2016

SandJacking: Sustituir apps legítimias en tu iOS con acceso físico

En la pasada HITB, Hack in the Box, se hizo pública una nueva vulnerabilidad, por lo que a Apple le tocará parchear próximamente. El ataque consiste en intercambiar aplicaciones legítimas con versiones maliciosas, siempre y cuando se tenga acceso físico al dispositivo. Esto afecta también a las últimas versiones del sistema operativo de iOS. El investigador Chilik Tamir demostró que la mitigación de un iOS a este tipo de ataque era incompleto. Apple no quiso realizar comentarios sobre la vulnerabilidad que ha sido comentada en la conferencia HITB. Al parecer, la empresa de Cupertino se encuentra trabajando en un parche.

La existencia de una serie de factores permite llevar a cabo el ataque. El primer ataque de Tamir, el cual se dio a conocer en la Black Hat Asia permitía intercambiar versiones legítimas de aplicaciones. Posteriormente, Tamir encontró otra forma de saltarse la protección de iOS. La técnica llamada SandJacking, permite a un atacante acceder a los contenidos de la sandbox de una aplicación. El ataque de SandJacking funciona mediante la primera copia de seguridad del dispositivo, eliminando la solicitud original y la instalación de aplicaciones no legítimas. Al iniciar una restauración de la copia de seguridad en el dispositivo, éste volverá a surgir. El ataque requiere que los usuarios aprueben aplicaciones manualmente. El investigador hizo la prueba de concepto con un Skype malicioso, ya que pasaba desapercibido.

Figura 1: Suplantación de apps

El investigador indicó que si bien el acceso físico al dispositivo puede ser un impedimento, la policía, los empleados de un taller de reparaciones, o incluso miembros de la familia que desear espiar a los otros, podrían utilizar su herramienta para llevar a cabo el proceso de infección. Cualquier persona con acceso al dispositivo puede ejecutar código e instalar malware de forma anónima. Los requisitos están claros, se necesita el dispositivo y el código de acceso, en el caso de que esté configurado. Aquí tienes las diapos de la presentación completa.

Figura 2: Diapositivas de la presentación de SandJacking

Hay que recordar casos como XCodeGhost o WireLurker, que en los últimos tiempos han destapado algunas carencias en el sistema de protección de iOS. El elemento común en la mayoría de estos incidentes es que los desarrolladores con los certificados emitidos por Apple desde el Programa de Empresa iOS eran capaces de escribir aplicaciones maliciosas y son confiadas por Apple.

jueves, 19 de noviembre de 2015

Ahora puedes usar Virus Total para analizar OS X malware

En Abril de 2015, durante la conferencia RSA, Google comentó algo extraño para muchos. Denominó PHA, aplicaciones potencialmente dañinas, a aquellas aplicaciones que pueden ejercer alguna acción dañina en el dispositivo. Google comentó que no valía la pena preocuparse porque menos de 1% de los dispositivos Android tienen un PHA instalado. Si analizamos los datos, un 1% significa más de 10 millones de dispositivos Android, ya que se supone que hay más de mil millones de dispositivos.

En definitiva, VirusTotal es utilizado para analizar binarios de Windows y Android, pero hoy en día también es utilizado para analizar aplicaciones de OS X en una sandbox. ¿Qué se puede subir? Se pueden subir imágenes de disco DMG o un archivo Mach-O, que es el equivalente a un archivo PE en Windows. En la imagen se puede ver como subimos un fichero en formato DMG a VirusTotal, y éste lo analizará. Hoy día es interesante tener disponible esta funcionalidad y poder aprovechar del potencial de VirusTotal.

Figura 1: Subida de fichero DMG y análisis

Podemos ver los resultados de más de 53 motores de Antivirus y se obtiene un reporte con toda la información sobre los resultados. Además, tenemos la posibilidad a través de VirusTotal de que el fichero pueda ser ejecutado en una sandbox, lo cual puede ayudar a detectar un comportamiento anómalo, el cual por firma no detectaremos.

Figura 2: Fichero analizado

Es cierto que el riesgo de infección en un sistema OS X es inferior al de un sistema Windows, pero también hay que recordar que el aumento de la cuota de mercado en estos sistemas hace pensar que el porcentaje va aumentando.

viernes, 16 de octubre de 2015

Guía de uso de rootless en OS X El Capitán de JNUC'15

Guía sobre uso de Rootless en OS X
En estas fechas se ha celebrado la JNUC, JAMF Nation User Conference, celebrada en Minneapolis. En una de las charlas se ha presentado una guía basada en el modelo defensa en profundidad. Para los que no estén muy cerca de dicho modelo se refiere a la implementación de distintas capas de seguridad por niveles, yendo desde el nivel físico al nivel de aplicación, pasando previamente por perímetro, red interna y bastionado de servidores. 

En la charla se hace un repaso por una serie de elementos para fortificar o realizar hardening a los sistemas OS X. Los elementos que se trabajan son los que todos vosotros ya conocéis en mayor o menor medida. Desde hablar de Gatekepeer y sus usos y configuraciones hasta hablar de sandboxing, pasando por diferentes permisos POSIX, o la nueva capa de seguridad denominada rootless.  Ya hemos hablado de rootless como una declaración de guerra de Apple contra intenciones de romper sus sistemas. Además, es una de las novedades más importantes respecto a la seguridad de los sistemas OS X.

Figura 1: System Integrity Protection

Una vez que la charla llega al System Integrity Protection y la configuración de rootless se puede ver como las slides son de esta nueva característica. Se detalla la configuración de rootless en la guía y cómo realizar pequeños ejemplos que demuestren el funcionamiento del sistema. Charla y slides recomendadas para que aprendáis más sobre elementos de seguridad en OS X.

sábado, 26 de octubre de 2013

Más seguridad de Apple Safari 7.0 en OS X 10.9 Mavericks

Con el lanzamiento de OS X 10.9 Mavericks ha venido también Apple Safari 7.0, donde como ya vimos en su Security Advirosry se habían arreglado 21 CVEs de seguridad. Además de ese arreglo de bugs, y de las novedades en cuanto a funcionalidad que ofrece, hay algunos detalles respecto a la seguridad que son dignos de contar, así que vamos a intentar resumirlos en este artículo de forma concisa.

Un proceso para cada pestaña

Desde hace mucho tiempo se reclamaba una opción similar a ésta. Google Chorme e Internet Explorer desde hace tiempo hicieron la división de procesos por pestañas, haciendo que si una pestaña se bloquease por culpa del mal funcionamiento de la web renderizada en ella, el sistema pudiera seguir funcionando. Esta opción se ha metido por fin en Apple Safari 7.

Figura 1: Monitor de Actividad con Apple Safari 7.0 en OS X Mavericks

Para comprobarla basta con abrir varias pestañas en un Apple Safari 7 y luego abrir el Monitor de Actividad, ir a la vista de Energía y desplegar Apple Safari 7. Allí se podrá ver lo que aparece en la imagen, un proceso para cada pestaña de navegación, y procesos independientes para plug-ins y módulos de red.

Plug-ins en Sandbox: modo Safe o Unsafe

En la parte de gestión de plug-ins ahora los más populares corren en una sandbox, para mitigar el impacto de los posibles bugs en Adobe Flash, Apple QuickTime, Microsoft Silverlight u Oracle Java en la seguridad global del sistema. Para configuralos hay que ir a las Opciones de Seguridad.

Figura 2: Gestión de plugins en Apple Safari 7.0

En las opciones de un plug-in, si corre en la sandbox, tendremos la opción de ejecutarlo también fuera de ella en caso de que de problemas de seguridad. Ese modo es el modo llamado "Unsafe".

Figura 3: Adobe Flash Player corre en modo Safe y puede pasar a Unsafe

Cuando un plug-in no tiene la opción de correr en modo Unsafe, es que está siendo ejecutado ya fuera de la sandbox, ya que esa posibilidad solo existe para los plug-ins que Apple ha permitido ejecutarse en modo sandbox.  Si se selecciona la opción de Ask, se podrá ejecutar en unos sitios sí, y en otros sitios no de forma permanente, creándose listas blancas y listas negras.

Opciones de Autofill

Estas características no son nuevas, pero viendo el reciente descubrimiento de nuestro compañero en Eleven Paths, que permitía robar los datos de Autofill en Google Chrome a un usuario, creemos que tal vez es bueno recordar que Apple Safari 7.0 también tiene esas opciones, y que por defecto están activadas.

Figura 4: Opciones de Autofill configuradas por defecto

Revisa su configuración si no quieres utilizarla, y mira los datos que tienes marcados para usar con Autofill. Incluso las contraseñas se pueden rellenar con Autofill, así que darle un vistazo para ver lo que has dejado en manos de tu navegador puede ser una buena opción.

Figura 5: Opciones de Autofill para contraseñas

Recuerda que hay herramientas para extraer las contraseñas almacenadas en ellas en local, como Apple Safari Decryptor que las recupera en caso de que alguien tenga acceso al sistema.

Actualizaciones de componentes automáticas

Además de las opciones de seguridad de los plug-ins para la sandbox, tienes que tener presente que puedes configurar para ellos la actualización automática cuando haya una nueva versión, algo que te lo recomendamos para evitar tener versiones out-of-date que puedan incluso ser bloqueadas por una nueva actualización de Apple Safari o de XProtect.

Figura 6: Opciones de Actualizaciones Automáticas para plug-ins

Más opciones de privacidad

Por último, nos gustaría recordarte que las opciones de privacidad para Apple Safari que recogimos en la serie de tres artículos siguen siendo válidas, así que si usas este navegador, te conviene darles una lectura en detalle.
- Privacidad en Apple Safari: El Historial de Navegación
- Privacidad en Apple Safari: Las Descargas
Privacidad en Apple Safari: La Caché y las Cookies
Ahora solo debes configurar el navegador a tu gusto, para que las opciones de seguridad y privacidad sean de tu agrado y puedas usarlo sabiendo cuáles son los límites a los que llega la protección de tu Apple Safari.

jueves, 26 de julio de 2012

OS X Mountain Lion: Novedades en seguridad


Con la salida de OS X Mountain Lion os presentamos algunas de las novedades interesantes en el ámbito de la seguridad. Se puede decir que Apple empieza a tomarse en serio el mundo de la seguridad, tal y como ocurrió en su día con MicrosoftLas novedades más esperadas y que más revuelo han porporcionado al mundo de la manzana son las siguientes: 

Sandboxing en todas las aplicaciones

Una sandbox aisla la ejecución de una herramienta para evitar la ejecución de código malicioso en el sistema. En OS X Mountain Lion se aisla la ejecución de las aplicaciones de componentes críticos del sistema operativo y de gestión de datos privados. Se añade sandboxing a nuevas aplicaciones como las notas, recordatorios o el Game Center y se optimiza la ejecución de la sandbox en aplicaciones que ya disponían de ella, como con el cliente de correo Mail o FaceTime. Para todas las aplicaciones que se distribuyan por medio de la Mac App Store será obligatorio el uso de sandbox, aunque Apple no lo haya hecho en su Apple Configurator.

Gatekeeper 

Esta utilidad, Gatekeeper, controla qué aplicaciones se pueden descargar y ejecutar y cuales no, pero la decisión final sigue siendo a cuenta del usuario. Esta aplicación evitará que los usuarios menos avanzados caigan en las redes de los creadores de malware.

Existirán 3 niveles de seguridad para ver qué política se ejecuta sobre el sistema. La política más restrictiva sólo permitirá la instalación de aplicaciones que provengan de la Mac App Store.

El segundo nivel de restricción, el cual vendrá configurado por defecto, amplia el mercado de aplicaciones a aquellas que han sido desarrolladas por programadores certificados por Apple. Por último, se dispone de la opción o tercer nivel dónde se dejará las cosas como están en la acutaildad, es decir, no se tomará ninguna medida de prevención con el tema de las aplicaciones. Como última novedad hay que decir, que los usuarios de Mac OS X Lion también podrán disfrutar de GateKeeper.

Actualizaciones de seguridad del sistema y las aplicaciones de la Mac App Store

Hoy en día es muy importante tanto para particulares como empresas disponer de su software actualizado y con la nueva versión del sistema operativo se dan dos pasos más hacia la homogeneidad: Actualizaciones del sistema operativo mejoradas y actualización de software de terceros integrada.

Figura 1: Actualizaciones de seguridad en OS X Mountain Lion

El nuevo OS X Mountain Lion permitirá al usuario que su software de la Mac App Store se actualice automáticamente, al igual que los parches o actualizaciones del sistema. Está comprobado que la mayoría de las máquinas de los usuarios tienen sus puntos débiles en las actualizaciones que tienen pendientes en las aplicaciones  del seguridad y software de terceros.

Apple Safari: Antiphishing mejorado

El phishing permite a los usuarios malintencionados mostrar un entorno muy parecido al real para llevar a las víctimas a caer en el engaño. De este modo, se consigue información privada de las víctimas, como pueden ser nombres de usuario, contraseñas, sesiones, tarjetas de crédito, etcétera. Apple Safari en la nueva versión vendrá con nueva tecnología anti phishing mejorada para proteger a los usuarios de este tipo de estafas.

FileVault 2 se mejora: Discos externos con FDE y Time Machine

La nueva versión de FileVault 2 estará disponible con OS X Mountain Lion. El cifrado de los datos, hoy en día es imprescindible, y en la nueva versión de FileVault 2 no solo se podrá hacer uso de Full Disk Encryption con AES 128, sino que también se podrá cifrar cualquier unidad extraíble por lo que unido al soporte de Time Machine, se podrá disponer de los archivos de respaldo o backup cifrados y protegidos.

XProtect: Anti malware mejorado

Después de lo pasado en el último año, Apple no está dispuesta a seguir ignorando el mundo del malware, por lo que en OS X Mountain Lion, la tecnología XProtect será mejorada, para dar un mejor conjunto de herramientas defensivas para luchar contra el software malicioso procedente de los archivos descargados de Internet, que serán analizados por el sistema operativo para verificar que no disponen de malware. Si ocurriese esto, OS X  Mountain Lion avisará y ofrecerá la posibilidad para moverlo a la papelera.

Aún así, entendemos que distará aún de tener todas las opciones de un anti malware profesional, ya que Apple está apostando más por uso de code-signing como en GateKeeper en lugar de tecnologías reactivas.

¿Y si te  roban el Mac? Find My Mac
 
Apple ha explicado que si tu Mac es robado o "perdido" se podrá encontrar gracias a iCloud y el propio sistema operativo del equipo. Se podrá utilizar la herramienta Find My iPhone un dispositivo como iPhone o iPad para localizar al equipo. Si el equipo no se encuentra conectado a Internet cuando se solicita que dé señales de vida, se puede programar que cuando el equipo se conecte a Internet notifique su posición mediante un correo electrónico.

Se puede dejar un mensaje para el ladrón... indicándole que vas a bloquear el equipo con un código que sólo tu conoces, al menos si no disfrutas tu el equipo, que no lo haga él. Y por último, se podrá lanzar una señal remota para borrar los datos personales y restaurar el Mac a los ajustes de fábrica.

Esperamos con ganas poder disfrutar del nuevo sistema operativo y poder estudiarle a fondo para contarlo en Seguridad Apple. ¿Preparados para el nuevo felino?

sábado, 7 de julio de 2012

Apple Configurator 1.1: Novedades sin SandBox

Además de iPhone Configuration Utilitiy, Apple tiene más herramientas para la gestión de dispositivos que hay que tener presentes. Una de ellas es Apple Configurator - disponible de forma gratuita para Mac OS X en la Mac App Store -, de la que os estamos preparando un artículo extenso para que podáis usarlo de referencia. 

Esta utilidad sirve para hacer aprovisionamiento de dispositivos en una pequeña o mediana organización, permitiendo asignar perfiles de configuración - creados como con iPhone Configuration Utility, y distribuir aplicaciones en ellos de manera automática, una vez que el dispositivo es asignado a una persona concreta, perteneciente a un grupo de usuarios en particular.

Figura 1: Apple Configurator 1.1

La gran ventaja de la herramienta es la posibilidad de distribuir licencias de las aplicaciones instaladas en cada dispositivo de manera automática, lo que ayuda a centralizar la compra por volumén (VPP - Volumen Purchase Program) asociándolo todo a una única cuenta de la App Store.

Figura 2: Asignación de aplicaciones VPP en compra de aplicaciones

Apple ha puesto a disposición pública la versión Apple Configurator 1.1, lo que supone la primera revisión de la herramienta, y donde se han mejorado algunos aspectos, como son:
-  Una nueva preferencia que permite que no se haga la renovación automática de aplicaciones o perfiles instalados en el dispositivo.
- Mejora de uso en la instalación de aplicaciones VPP y redemption codes.

- Nueva preferencia para evitar el borrado de aplicación y perfiles de configuración instalados por el usuario cada vez que un dispositivo supervisado es conectado.
- Nueva preferencia para evitar que se re-apliquen los perfiles de configuración cada vez que un dispositivo supervisado es conectado.
- Nueva alerta desde el Profile Editor que avisa de cuando un perfil de configuración no puede ser asignado a un dispositivo porque falta un valor en un campo.
Además de estas novedades, que vienen a solucionar problemas detectados en el uso de la herramienta por organizaciones con diversas problemáticas, hay que destacar que la publicación de esta versión ha suscitado muchas críticas por parte de los desarrolladores, ya que mientras que obliga a todo el mundo a que las aplicaciones estén en Sanbox en la Mac App Store desde el 1 de Julio, Apple Configurator 1.1. no hace uso de ella, saltándose la propia Apple su política.

Figura 3: Criticas a Apple Configurator por no estar en SandBox

sábado, 5 de noviembre de 2011

Apple se preocupa por el malware y exigirá implementar SandBox en las aplicaciones de la Mac App Store

Apple se está empezando a preocupar por lo que puede ser un serio problema en sus plataformas Mac OS X: El malware. Solo hay que ver cómo Microsoft no se lo tomó en serio en sus inicios - no fue hasta la Trustworthy Computing initiative que acogió a Windows Vista cuando se lo tomó realmente en serio - y tuvo que sufrir durante años que malware, de forma sencilla, infectara volúmenes ingentes de equipos, y lo que fue peor, que se instaurase de forma definitiva una industira del malware alrededor de sus plataformas. Apple no quiere que le pase lo mismo, y empieza a tomar medidas.

Negar la existencia de malware en Mac OS X, y un creciente aumento en cantidad y calidad del mismo es de auténtico necio. Existe, está, y desde el año 2007 se conocen las primeras campañas de fraude profesional con troyanos para Mac OS X, como analizó Bernardo Quintero.

En este último año, el volumen de malware para Mac OS X se ha disparado, OSX/MacDefender (MacGuard, MacProtector, MacSecurity, MacShield), DarkCometX RAT, BlackHole RAT, Boonana Worm, Koobface Worm, Incognito RAT, DevilRoober (OSX/Miner-d), OSX/Flashback, OSX/Tsunami, OSX/Imuler (OSX/Revir), etc... han aparecido y mutado para proliferar por todo Internet.

Es por eso que Apple quiere fortificar las aplicaciones que se vendan desde la Mac App Store, para evitar distribuir aplicaciones que, por fallos de seguridad, se conviertan en una puerta de entrada al sistema operativo Mac OS X. Para ello, va a exigir a todos los desarrolladores que, a partir de Marzo de 2012 todas las aplicaciones implementen un sistema de SandBoxing estándar.

Figura 1: Anuncio en el sitio de desarrolladores de Apple

La tecnología de Sandbox permite ejecutar en un entorno virtualizado un software. Esto impide que el programa tenga acceso a la memoria y la API real del sistema, y evita que un exploit pueda acceder a partes sensibles del sistema operativo que ejecuta el programa, lo que aumentará, sin duda, la protección de la plataforma.

Hasta el momento, para utilizar la tecnología SandBox que viene en el sistema, los administradores de una plataforma podían hacerlo voluntariamente con las aplicaciones en Mac OS X con el comando sandbox-exec, tal y como explicamos en el artículo de SandBoxing en Mac OS X.

jueves, 26 de agosto de 2010

Sandboxing en Mac OS X (II de II)

========================================================================
- Sandboxing en Mac OS X (I de II)
- Sandboxing en Mac OS X (II de II)
========================================================================

Continuando con la primera entrada del articulo 'Sandboxing en Mac OS X', lo retomaremos con una serie de reglas que nos ayudarán a crear y configurar sandboxs seguras:

network-inbound / network-outbound

Esta regla se aplica al tráfico de red entrante (network-inbound) o saliente (network-outbound). Si se utiliza el comodín ‘*’ en el nombre de la regla (network*), las restricciones se aplicarán tanto al trafico entrante como saliente. El siguiente fichero de reglas nos permite realizar conexiones salientes, pero nos prohíbe las entrantes.

(version 1)
(allow default)
(deny network-inbound)


Este otro script, nos permitirá realizar conexiones salientes, pero no recibir entrantes.

(version 1)
(allow default)
(deny network-outbound)
(allow network-inbound)


file-read-data

Esta regla hace referencia a la lectura del contenido de los ficheros. Si queremos evitar que un proceso pueda tener acceso de lectura al fichero ‘/etc/passwd’, podremos prohibirlo con la siguiente regla.

(version 1)
(allow default)
(deny file-read-data
(regex “/etc/passwd$”))


file-read-metadata

Con esta regla podemos indicar si podemos leer los metadatos de un archivo, o dicho de otro modo, los permisos del archivo.

(version 1)
(allow default)
(deny file-read-metadata
(regex “/etc/passwd$”))


file-write-data

Esta regla evita que se pueda escribir en un archivo ya existente, pero no evita que se pueda crear el archivo con información, si este no existía previamente, o que este pueda ser borrado. Si se desea proteger un fichero, es aconsejable utilizar ‘file-write*’ en su defecto.

(version 1)
(allow default)
(deny file-write-data
(regex “/tmp/i64$”))


file-write*

Esta es la regla aconsejada para la protección de archivos, en vez de ‘file-write-data’. Esta regla protege de la creación, modificación y borrado.

(version 1)
(allow default)
(deny file-write*
(regex “/tmp/i64$”))


process-exec

Evita la ejecución de los procesos indicados. En el siguiente script bloquearemos todos los comandos excepto ‘/bin/echo’ y ‘/bin/bash’.

(version 1)
(allow default)
(deny process-exec)
(allow process-exec)
(regex “/bin/bash$”)
(regex “/bin/echo$”))


Debido a la poca documentación existente sobre la sintaxis de las reglas de sandbox-exec, os invitamos a que publiquéis aquí reglas que os resulten útiles, y se puedan incluir en el artículo.

========================================================================
- Sandboxing en Mac OS X (I de II)
- Sandboxing en Mac OS X (II de II)
========================================================================

miércoles, 25 de agosto de 2010

Sandboxing en Mac OS X (I de II)

========================================================================
- Sandboxing en Mac OS X (I de II)
- Sandboxing en Mac OS X (II de II)
========================================================================

El concepto informático de ‘Sandboxing’ es el de separar o restringir las operaciones que un proceso pueda realizar del resto del sistema, de tal modo que éste pueda ejecutarse con determinadas restricciones sin miedo a que pueda dañar nuestro equipo.

En Mac OS X, desde la versión Leopard, existe un comando llamado ‘sandbox-exec’ que permite la ejecución de comandos en una sandbox, el cual se puede configurar a través de ciertas reglas.

No existe demasiada documentación sobre estas reglas, por lo que este pequeño artículo tiene como intención añadir un poco de luz a las reglas más útiles para llevar a cabo ejecuciones en sandboxes seguras.

La sintaxis para la creación de sandboxes, con las reglas cargadas desde un fichero de texto es la siguiente: ‘sandbox-exec -f FicheroDeReglas Aplicación’, como se puede ver en la siguiente imagen donde se ejecuta una shell.


La estructura del fichero de reglas siempre debe comenzar con la línea ‘(version 1)’ seguido de las reglas que se quieran aplicar.

Dos de las reglas más básicas son ‘(allow default) / (deny default)’ y ‘(debug deny) / (debug all)’.

(allow default) / (deny default)

La regla ‘(allow default)’ indica que, por defecto se permite realizar cualquier acción, tal y como si el proceso no se corriera en una sandbox, a excepción de las reglas que se indiquen posteriormente.

En el caso contrario, la regla ‘(deny default)’ actuará denegando todas las acciones excepto las que se indique más adelante.

Como se puede ver, configuran el comportamiento por defecto para todo lo no definido dentro del fichero.

(debug deny) / (debug all)

Esta regla indica si se desea guardar o no un fichero de log con información sobre las acciones que se ejecutan en la sandbox. En caso de que si se desee, se puede especificar si guardar todas las acciones realizadas o únicamente las que estén prohibidas. Si no se quiere registrar información sobre una regla en concreto se puede utilizar ‘(with no-log)’ en ella para evitarlo.

El fichero de log se guarda, por defecto, en la ruta‘/var/log/system.log’. La siguiente captura muestra el fichero de log generado al ejecutar un comando prohibido por este fichero de reglas. Como se puede ver, el fichero de las reglas prohíbe de forma explíctia el uso de la red:

(version 1)
(allow default)
(debug deny)
(deny network*)


Ya que en el anterior fichero de reglas se ha hecho uso de la regla ‘network*’, en la segunda parte de este artículo se explicará en más detalle, junto con otras.

========================================================================
- Sandboxing en Mac OS X (I de II)
- Sandboxing en Mac OS X (II de II)
========================================================================

Entrada destacada

Proteger tu cuenta de Google y de Gmail con Latch Cloud TOTP #Latch #Gmail #Google

La semana pasada se liberó la nueva versión de Latch y nuestro compañero Chema Alonso hizo un repaso de todo ello en su artículo Latch...

Otras historias relacionadas

Entradas populares