Google Project Zero confirma que millones de Android vienen con malware preinstalado

Da igual el móvil que compremos: todos vienen con aplicaciones preinstaladas. Estas apps nos facilitan el uso del móvil nada más arrancarlo por primera vez, aunque a cambio de ello también tenemos hasta decenas de apps que no vamos a necesitar y que tendremos que borrar. Ahora, la propia Google ha reconocido que hay millones de móviles Android con apps preinstaladas que incluyen malware.

Así lo ha revelado Project Zero, la división de seguridad de Google encargada de encontrar vulnerabilidades y fallos en el software que usamos a diario. En el pasado hemos visto cómo muchas apps que se llegaban a colar en la Play Store robaban datos de los usuarios o instalaban malware adicional. Esto no era un gran problema si tenemos en cuenta que esas apps había que instalarlas manualmente. El peligro de que esto se pase a las apps preinstaladas tiene que ver con que, cuando un usuario se compra un móvil, éste se cree que está limpio.

Sin embargo, millones de nuevos móviles no lo están, e incluso aunque las apps incluidas no sean nocivas, sí que éstas pueden tener mecanismos para descargar contenido que sí lo sea. Normalmente los móviles tienen al menos 100 aplicaciones preinstaladas, incluyendo las que el usuario puede ver y otras del sistema que están ocultas. La cifra puede llegar a dispararse a 400 en algunos terminales.

Maddie Stone ha publicado en la Black Hat [PDF] lo que ha descubierto su equipo, alertando de que es necesario un análisis y unas auditorias mucho más exhaustivas de los terminales que llegan al mercado. Estos análisis deben hacerse sobre todo en los móviles basados en Android's Open-Source Project (AOSP), que viene preinstalado en los móviles más baratos y de marcas blancas en muchas ocasiones.

Más de 200 fabricantes de móvil tenían apps con malware preinstalado

De todos los terminales analizados, Google afirma que más de 200 fabricantes diferentes tenían software que contenía malware. Esto es relativamente fácil de hacer por los atacantes, ya que sólo tienen que convencer a una compañía y pagarles para que preinstalen una app en miles de móviles con la que luego acceder al terminal de manera remota.

De todo el malware que encontraron, hubo dos campañas que fueron realmente preocupantes: Chamois y Triada. Chamois mostraba anuncios falsos, instalaba apps indeseadas en segundo plano, descargaba plugins, e incluso podían enviar mensajes SMS a números de pago. El malware estaba preinstalado en 7,4 millones de dispositivos. Triada es una versión anterior a Chamois, y también muestra anuncios e instala apps. Entre marzo de 2018 y marzo de 2019, la investigadora afirma que han conseguido reducir de 7,4 millones a sólo 700.000 los dispositivos que traían Chamois preinstalado.

Protegernos ante estas infecciones es bastante difícil. Entre lo poco que podemos hacer encontramos el comprar siempre móviles de marcas reputadas y no copias chinas en AliExpress o DHGate. También es recomendable eliminar todas las apps que podamos, y si podemos rootear el móvil, es conveniente hacerlo para eliminar aquellas de las que sospechemos, haciendo previamente una copia de seguridad del sistema por si rompemos algo.

Fuente: ADSLZone

Seguir leyendo...

Google ya permite autenticación biométrica de sus cuentas

El acceso a las cuentas de Google y algunos de sus servicios será posible a través de la autenticación biométrica o pantalla de bloqueo de un smartphone con Android, según el anuncio del gigante de Internet.

Google sigue en camino de eliminar el uso de las típicas contraseñas para accesos en Internet. No es una sorpresa y son buenas noticias teniendo en cuenta la cantidad de servicios que ofrece Google. Las contraseñas se consideran desde hace tiempo totalmente insuficientes para garantizar la seguridad y la industria tecnológica se ha dirigido hacia métodos biomátricos más seguros.

Con ese fin, la compañía ha implementado un mecanismo para permitir que los dispositivos Android usen los sensores de huellas digitales (o el bloqueo de pantalla) para iniciar sesión en las cuentas de Google. La función está disponible desde hoy en dispositivos de marca propia Pixel y llegará en los próximos días a terminales con Android 7.0 o versiones superiores del sistema operativo.

Google usa los FIDO2, W3C WebAuthn y FIDO CTAP, un conjunto de estándares desarrollados por la industria los últimos años para alejar al mundo de la dependencia de las contraseñas al facilitar el uso de otros métodos de autenticación más seguros como llaves de seguridad físicas, huellas digitales u otros sistemas biométricos.

"Un beneficio importante de usar FIDO2 en lugar de interactuar con las API nativas de huellas digitales en Android es que estas capacidades biométricas ahora están, por primera vez, disponibles en la Web, lo que permite que las aplicaciones nativas y los servicios web utilicen las mismas credenciales", explican desde Google.

Esto garantiza que un mecanismo fiable y familiar que utilizamos a diario en dispositivos móviles se pueda emplear para iniciar sesión en cuentas de Google, así como en otras aplicaciones y servicios que utilizan el marco de inicio de sesión único de la compañía. En la práctica, no necesitaremos ingresar una contraseña cada vez que iniciemos sesión en algún servicio web, limitando -por ejemplo- los ataques de "phishing".

Cuentas de Google desde Android

Si quieres probarlo necesitas:

• Smartphone con Android 7.0 o superior
• Cuenta personal de Google añadida al dispositivo
• Un bloqueo de pantalla válido configurado en el terminal

Para la ejecución:

• Abre el navegador Chrome en el terminal con Android
• Navega a https://passwords.google.com
• Elige un sitio web para ver o administrar una contraseña guardada
• Sigue las instrucciones para confirmar que intentas iniciar sesión

Google dice que solo es el comienzo: "Esta nueva capacidad marca otro paso en nuestro viaje para hacer que la autenticación sea más segura y fácil de usar para todos. A medida que sigamos adoptando el estándar FIDO2, comenzarás a ver más lugares donde se aceptan alternativas a las contraseñas como mecanismo de autenticación para los servicios de Google y Google Cloud".

Puedes consultar esta presentación para tener una visión temprana de los casos de uso con los que están experimentando.

Fuente: Blog de seguridad de Google

Seguir leyendo...

Fallo en WPA en Ubuntu permite obtener contraseñas

Hace unos instantes, Canonical ha lanzado unos parches para corregir una vulnerabilidad WPA que, aunque es cierto que sería difícil de explotar, podría hacer que un usuario malintencionado robara nuestras contraseñas. En su informe, la compañía que dirige Mark Shuttleworth dice que la vulnerabilidad podría ser explotada por un "atacante remoto", pero teniendo en cuenta que WPA guarda relación con conexiones WiFi, todo parece indicar que para hacerlo deberíamos estar conectados a la misma red, siendo lo más habitual una pública como las que hay disponibles en algunos cafés o tiendas.

En un principio, el fallo solo afecta a Ubuntu 19.04 Disco Dingo y Ubuntu 18.04 LTS Bionic Beaver, y digo "en un principio" porque no descarto que publiquen un nuevo informe para otras versiones del sistema operativo desarrollado por Canonical, como podría ser Ubuntu 16.04 Xenial Xerus. De hecho, Canonical menciona que hay que actualizar dos paquetes, pero en el momento de escribir estas líneas a mí solo me ha aparecido uno.

La vulnerabilidad WPA podría explotarse de forma remota

Los paquetes que hay (o habrá) que actualizar son los hostapd – 2:2.6-21ubuntu3.2 y wpasupplicant – 2:2.6-21ubuntu3.2 para Ubuntu 19.04 Disco Dingo y hostapd – 2:2.6-15ubuntu2.4 y wpasupplicant – 2:2.6-15ubuntu2.4 para Ubuntu 18.04 LTS Bionic Beaver. Como ya he mencionado anteriormente, podemos confirmar que ya está disponible el segundo parche para Disco Dingo, pero el primero aún no está disponible.

Hace menos de 24 horas, Canonical publicó otros parches para solucionar una vulnerabilidad PHP. Lo mejor es aplicar los parches de seguridad tan pronto en cuanto nos sea posible y reiniciar para que los cambios surtan efecto.

Fuente: Ubuntulog

Seguir leyendo...

¿Incumplimos el RGPD si nuestra empresa no acualiza a Windows 10 en 2020?

Windows 7 dejará de recibir actualizaciones de seguridad en apenas 6 meses. El fin del soporte del sistema operativo que hoy en día todavía se mantiene en gran parte de los ordenadores de muchas organizaciones puede traer una problema añadido en lo que respecta a la protección de datos. ¿Incumplimos el RGPD si nuestra empresa no acualiza a Windows 10 en 2020?

Uno de los cambios fundamentales del Reglamento General de Protección de Datos, está en la protección de los datos personales desde el propio diseño. Las empresas deben tomar las medidas que sean necesarias para mantener seguros dichos datos. Si mantenemos un sistema operativo que ya no recibe actualizaciones de seguridad podemos estar incurriendo en una negligencia.

Esto puede pasar desapercibido si no ocurre nada o por el contrario puede ser una catástrofe si tenemos un incidente de seguridad, se comunica a la Agencia Española de Protección de Datos, algo obligatorio de hacer en un plazo de 48 horas desde la detección del problema. Tras un expediente nos impone una sanción porque no hemos tomado las medidas adecuadas para la protección de dichos datos.

La ley no nos dice que medidas debemos tomar, algo que puede despistar a muchas empresas. No nos indica si debemos tener un antivirus, un cortafuegos o si tener sistemas operativos potencialmente vulnerables dentro de nuestra red es susceptible o no de sanción. Y en esta duda tienen que trabajar muchas empresas.

Lo habitual hasta hace unos años cuando un sistema operativo dejaba de recibir actualizaciones era que lo ordenadores se fueran renovando paulatinamente, pero no era algo imperativo. Así ocurrió con Windows XP, que siguió presente en muchas organizaciones años después del fin del soporte oficial. Incluso Microsoft lanzó alguna actualización fuera de ciclo para vulnerabilidades críticas.

En el caso de Windows 7 la cosa cambia por dos motivos. El primero es la entrada en vigor del RGPD. Y el segundo es que Microsoft si nos dará estas actualizaciones de seguridad si pagamos un extra. Por lo tanto ante un problema de seguridad, no se podría descartar que nos sanciones por no cumplir con la ley de protección de datos.

Fuente: Pymes

Seguir leyendo...

Cisco pagará 8,6 millones por vender software de videovigilancia con graves problemas de seguridad

Cisco pagará 8,6 millones de dólares para poner fin a la demanda que le enfrenta a varios organismos federales y estatales de Estados Unidos por exponerles a serios riesgos de ciberseguridad. De forma "voluntaria" la compañía de telecomunicaciones pagará 2,6 millones de euros al gobierno federal y otros 6 millones a distintas entidades públicas de 15 estados diferentes, que se habían unido para presentar una demanda conjunta.

Según explicaron los afectados en su momento, Cisco vendió a todos estos organismos software para cámaras de videovigilancia que tenía fallos graves a nivel de seguridad, y que podrían haber sido explotados con gran facilidad por cualquier grupo cibercriminal. Sin embargo y lo que resulta aún más preocupante, es que al parecer Cisco era plenamente consciente de los problemas que presentaba el software: Video Survellaince Manager, el software en cuestión y que fue distribuido entre 2008 y 2014, fue desarrollado en un primer momento por Broadware, compañía que Cisco adquirió en 2007.

En defensa de Cisco, Mark Chandler, vicepresidente ejecutivo de la compañía, ha explicado que "Broadware utilizó de forma intencionada una arquitectura abierta, para permitir la implementación de aplicaciones y soluciones de seguridad adaptadas a las necesidades de cada cliente. Es cierto que debido a esa arquitectura abierta, teóricamente los feeds de vídeo podrían haber sido susceptibles de haber sido atacados por un grupo hacker, pero no hay ninguna prueba de que ninguna de las cámaras de seguridad instaladas haya visto comprometida su seguridad. En 2009 publicamos un documento de 'Buenas prácticas' en el que recomendábamos a nuestro canal de distribución a que prestasen atención especial a la hora de securizar este software en concreto. Además en 2013, aconsejamos a todos nuestros clientes que actualizasen a una nueva versión que corregía todos estos problemas".

Y en parte todo esto es cierto. En 2013 Cisco publicó un parche de seguridad para su Video Surveillance Manager en cuya descripción, podía leerse lo siguiente: "multiple security vulnerabilities exist in versions of Cisco VSM prior to 7.0.0, which may allow an attacker to gain full administrative privileges on the system". ¿El problema? Que esas mismas vulnerabilidades estaban presentes en el sistema desde 2008.

El caso se hizo público en 2011, cuando alguien envió al buzón «para informantes anónimos» del despacho de abogados Philips&Cohen, pruebas de que "Cisco habría vendido directa e indirectamente a agencias federales, así como a entidades gubernamentales estatales y locales un sistema de vigilancia del que sabía que poseía problemas de seguridad peligrosos, no revelados e inaceptables".

Según este despacho de abogados, que en ese momento presenta la demanda, "el denunciante presentó varios informes detallados a Cisco que supuestamente revelan que cualquier persona con un conocimiento moderado de la seguridad de la red podría explotar este software para obtener un acceso no autorizado a los datos almacenados, pasar por alto los sistemas de seguridad física y obtener acceso administrativo a toda la red de un organismo gubernamental, todo ello sin ser detectado. A pesar de las repetidas advertencias internas sobre los defectos de VSM, Cisco supuestamente continuó vendiendo este software".

Fuente: Muy Seguridad

Seguir leyendo...

La filosofía de ATT&CK explicada

El proyecto MITRE ATT&CK]ha crecido durante los últimos cinco años, tanto en contenido como en el proceso para mantener ese contenido, para garantizar que siga siendo un recurso útil para la comunidad.

Ahora han publicado el documento técnico de filosofía de ATT&CK [PDF] para que sirva como recurso autorizado que describa el diseño y la filosofía detrás de ATT&CK porque es importante para ser transparentes sobre cómo se toman esas decisiones.

El documento técnico detalla la historia más allá de ATT&CK, así como algunos puntos de como cómo desglosar los elementos de ATT&CK y lo que significan varios términos. A menudo recibimos preguntas sobre qué datos usamos, de dónde provienen y cómo tomamos decisiones (más allá de las actualizaciones que enviamos), por lo que me complace que también cubramos esos aspectos en el documento. Tenemos la intención de que este sea un documento vivo, por lo que a medida que cambiemos, planeamos actualizarlo en consecuencia.

No todas las amenazas (potenciales) son iguales

ATT&CK se desarrolló con un caso de uso de manejo en mente: la mejor detección del comportamiento del ciber-adversario posterior al compromiso. Se lanzó el documento que describe gran parte de ese trabajo el año pasado, y es importante tener en cuenta este objetivo original para comprender el proceso que hemos desarrollado para actualizar ATT&CK. Aunque nuestro proceso tiene matices, lo impulsa un concepto central: uno puede priorizar cómo se defiende al enfocarse en el comportamiento documentado de amenazas.

Las amenazas persistentes (a veces denominadas amenazas persistentes avanzadas o APT) se nombran como tales porque tienen un objetivo que cumplir, e intentarán alcanzar ese objetivo varias veces y de muchas maneras diferentes cuando encuentren interrupciones en sus operaciones. Las amenazas persistentes pueden tomar muchas formas, desde actividades patrocinadas por el estado-nación interesadas en espionaje o robo de propiedad intelectual, hasta delincuentes con motivos financieros que se infiltran en instituciones financieras. Los actores de este espectro pueden usar técnicas muy similares entre sí.

El rango de posibles técnicas que los adversarios pueden usar es enorme. Uno puede ver lo que sucedió en el pasado, lo que está sucediendo ahora y lo que podría suceder en función de la investigación académica, los catálogos de vulnerabilidad o simplemente cualquier idea que alguien tenga en un día determinado. Es una gran variedad de cosas de las que preocuparse para cualquier organización, y es una tarea difícil lidiar con la complejidad de la tecnología mientras se equilibra el impacto de las decisiones de seguridad con la usabilidad. Reducir eso y enfocarse en actividades de amenazas empíricamente documentadas que ocurren en entornos abiertos es una forma útil de priorizar qué abordar primero, y eso sirve como la influencia central que impulsa los tipos de información dentro de ATT&CK.

Fuentes de información

Hemos utilizado varias fuentes diferentes de información sobre amenazas para documentar las técnicas ATT&CK, que incluyen:

• Informes de inteligencia de amenazas
• Presentaciones de conferencia
• Seminarios web
• Medios de comunicación social
• Blogs
• Abrir repositorios de código fuente
• Muestras de malware

MITRE es abierto sobre de dónde proviene la información sobre técnicas y amenazas, siempre que sea una fuente confiable y mejore la comprensión colectiva de la comunidad de las técnicas que pueden enfrentar. El equipo de ATT&CK tiene muchos años de experiencia colectiva en inteligencia de amenazas, defensa de redes y equipos rojos, y aplicamos regularmente esa experiencia en la selección y verificación de información.

¿Qué pasa con los equipos rojos y la investigación de nuevas técnicas?

Desafortunadamente, la información sobre amenazas disponible públicamente a menudo no es suficiente para tener una idea completa de lo que están haciendo los adversarios. Lo que se ve y se informa se basa en qué datos están disponibles en ese momento, quién los vio y que tan sensible es la información, lo que lleva a casos en los que la información sobre el comportamiento adversario no está disponible públicamente. Esto presenta un desafío para nosotros porque queremos mantener ATT&CK actualizado sobre las últimas Tácticas, Técnicas y Procedimientos (TTP) que los defensores deben conocer. Dada esta realidad, utilizamos varios métodos para tratar de aproximar lo que los adversarios están haciendo en la naturaleza.

• Eventos no reportados: no se informa todo lo que sucede. Las restricciones de información y la sensibilidad de los datos son una limitación real. Si una fuente creíble dice que una técnica está en uso libremente y hay suficiente información técnica disponible sobre cómo podría usarse, entonces es probable que haya evidencia suficiente sin tener un informe disponible públicamente para hacer referencia.
• Equipos rojos: a menudo son impulsados ​​por objetivos similares a las amenazas persistentes: ingresan sin ser detectados y logran un objetivo. A veces, las técnicas que usan los equipos rojos coinciden con lo que sucede en Internet, y otras no. Si varios equipos rojos usan con éxito ciertos tipos de técnicas a las que muchos de sus clientes son vulnerables, entonces es probable que un adversario del mundo real en algún momento termine usándolo también.
• Investigación de nuevas técnicas: se está publicando una gran cantidad de trabajo excelente que saca a la luz nuevos métodos para subvertir las medidas de seguridad. A veces, estas técnicas son detectadas rápidamente por las amenazas del mundo real, y otras veces se descubren nuevamente cuando se analizan datos antiguos con nuevos detalles, por lo que es importante que consideremos las técnicas recientemente descubiertas con cierto nivel de discreción según la probabilidad de que ser (o haber sido) usado.

Factores de decisión técnica

A veces tiene sentido agregar nuevas técnicas cuando recibimos una contribución o encontramos nuevos informes, pero otras veces podríamos volver a analizar o agregar detalles a una técnica existente, pero relacionada, para incluir la nueva información. Consideramos varios factores cuando incluimos nueva información para determinar dónde y cómo encaja en el modelo y la base de conocimiento:

• Objetivo: ¿Qué está logrando la técnica? Se pueden realizar técnicas similares de la misma manera para lograr diferentes tácticas. Del mismo modo, diferentes técnicas pueden lograr la misma táctica de diferentes maneras.
• Acciones: ¿Cómo se realiza la técnica? ¿Es el "disparador" diferente entre las técnicas que los distinguen a pesar de que el resultado puede ser el mismo o similar?
• Uso: ¿Quién lo está usando? ¿Varios grupos usan la técnica? Si es así, ¿cómo es el uso diferente o similar?
• Requisitos: ¿Cuáles son los componentes necesarios para usar una técnica y qué se ve afectado por su uso? (Por ejemplo, archivos, ubicaciones, cambios en el registro, llamadas a la API, permisos, etc.) ¿Cuál es la superposición de componentes entre técnicas? ¿Son distintos o similares?
• Detección: ¿Qué se necesita instrumentar para detectar el uso de la técnica? Esto está relacionado con los requisitos y las acciones, pero podría diferir según las técnicas relacionadas.
• Mitigaciones: ¿Qué opciones de mitigación están disponibles para la técnica? ¿Son similares o diferentes a otras técnicas que se realizan de la misma manera o tienen el mismo resultado?

La mayoría de las veces, ninguna de estas preguntas por si solas determinarán cómo incorporamos nueva información, pero considerar estos factores nos ayuda a pensar en la mejor manera de agregar información a ATT&CK de una manera útil.

Ayuda para continuar

Conservar el contenido en ATT&CK a veces puede ser más un arte que una ciencia, y esperamos que esta publicación de blog y el documento lo ayuden a comprender nuestro pensamiento. Sí, hay excepciones al proceso, que tratamos de documentar a medida que avanzamos y también utilizamos para cambiar la forma en que pensamos sobre el contenido futuro.

Aplicamos un proceso para evaluar la relevancia de la nueva información que nos lleva a veces a no incorporar algunos elementos de información; necesitamos mantenernos enfocados en los principios centrales que hacen que ATT&CK sea útil. A lo largo de los años, hemos recibido muchas contribuciones que no cumplían con los criterios que establecimos para ATT&CK, a pesar de que muchos tenían justificaciones buenas y bien razonadas de por qué debería incluirse. Independientemente de si incluimos contribuciones, apreciamos la disposición continua de la comunidad para ayudar. El proceso ha evolucionado a lo largo de los años y continuará evolucionando para satisfacer las necesidades de quienes usan y valoran ATT&CK.

Mantener ATT&CK también es mucho trabajo. Solo la de Empresa tiene hasta 219 técnicas y 69 grupos con un sorprendente 968 referencias. Esperamos que la comunidad brinde información valiosa, tanto en contenido como en proceso, para ayudar a mantenerla actualizada y relevante. Si tiene información que cree que debería incluirse, comuníquese con nosotros en [email protected] o en Twitter @MITREattack.

También continuaremos esta serie para hablar sobre algunas aplicaciones adicionales de ATT&CK y futuras mejoras.

Traducción: Raúl Batista de la redacción de Segu-Info
Autor: Blake Strom
Fuente: MITRE

Seguir leyendo...

Cuatro fallas críticas en RDS y otras 89 vulnerabilidades corregidas en Windows

Este mes Microsoft ha parcheado 93 fallos de seguridad y ha publicado dos avisos incluyendo mitigaciones para problemas relacionados con la seguridad que afectan a productos y servicios de su compañía. Se han encontrado cuatro nuevas vulnerabilidades críticas en Windows, las cuales permitirían ejecución remota de código (RCE) en Remote Desktop Services.

Descubiertos por el propio equipo de seguridad de Microsoft, las cuatro vulnerabilidades, CVE-2019-1181, CVE-2019-1182, CVE-2019-1222, y CVE-2019-1226, pueden ser explotadas por atacantes remotos no autenticados para tomar el control de un afectado sistema sin requerir ninguna interacción del usuario.

De estos cuatro CVEs, los 2 primeros son los más graves. De hecho, en el blog del propio Simon Pope -Director de Respuestas a Incidentes en el Centro de Repuesta de Seguridad de Microsoft (MSRC)- se apuntó que estos fallos eran susceptibles de incluir en su explotación capacidades de replicación y pivotaje propias de un gusano, recordando al fallo BlueKeep que Microsoft ya solucionó en mayo.

Al igual que la falla BlueKeep, estas nuevas vulnerabilidades también son susceptibles de ser explotadas por un posible malware para propagarse automáticamente de una computadora vulnerable a otra (wormeable). "Un atacante puede obtener ejecución del código a nivel de SYSTEM enviando un paquete RDP de autenticación previa especialmente diseñado a un servidor RDS afectado", advirtió Microsoft.

"Las versiones afectadas de Windows son Windows 7 SP1, Windows Server 2008 R2 SP1, Windows Server 2012, Windows 8.1, Windows Server 2012 R2 y todas las versiones compatibles de Windows 10, incluidas las versiones de servidor".

Aunque las dos primeras vulnerabilidades afectan a todas las versiones compatibles del sistema operativo Windows, el segundo conjunto de fallas (CVE-1222 y CVE-1226) solo afecta a las ediciones de Windows 10 y Windows Server.

Las nuevas vulnerabilidades no afectan a Windows XP, Windows Server 2003 y Windows Server 2008 ni afectan al Protocolo de escritorio remoto (RDP) que Microsoft desarrolló para los Servicios de escritorio remoto. Las vulnerabilidades residen en los Servicios de Escritorio Remoto, anteriormente conocidos como Servicios de Terminal Server, podrían ser explotados por atacantes remotos no autenticados enviando solicitudes especialmente diseñadas sobre el protocolo RDP a un sistema objetivo.

Además de esto, Microsoft también dice que la compañía no ha encontrado "ninguna evidencia de que estas vulnerabilidades sean conocidas por terceros o que hayan sido explotadas. Es importante que los sistemas afectados se reparen lo más rápido posible debido a los riesgos elevados asociados con vulnerabilidades susceptibles de gustar como estos", recomendó Microsoft.

Si no se los repara, estas vulnerabilidades de seguridad podrían permitir a los atacantes propagar malware malicioso de forma similar a como lo hizo WannaCry y NotPetya en 2017.

Además de estas cuatro fallas críticas de seguridad, Microsoft también ha corregido otras 89 vulnerabilidades, 25 de las cuales se consideran críticas y 64 importantes en gravedad.

Estas actualizaciones de seguridad de agosto incluyen parches para varias versiones compatibles de Windows y otros productos de Microsoft, incluidos Internet Explorer, Edge, Office, ChakraCore, Visual Studio, Servicios en línea y Active Directory Microsoft Dynamics.

Todas las vulnerabilidades críticas enumeradas este mes afectan varias versiones del sistema operativo Windows 10 y las ediciones del servidor y residen principalmente en Chakra Scripting Engine, y algunas también residen en la Interfaz de dispositivo gráfico de Windows (GDI), Word, Outlook, Hyper-V y VBScript Engine, LNK y Windows DHCP Server.

Además, aprovechando esta ocasión, Microsoft también recuerdo a los usuarios que Windows 7 y Windows Server 2008 R2 no tendrán soporte extendido y no recibirán actualizaciones a partir del 14 de enero de 2020.

Fuente: THN

Seguir leyendo...

Brecha de seguridad en empresa de biometría expone a un millón de personas

Las huellas digitales de más de 1 millón de personas, así como información de reconocimiento facial, nombres de usuario y contraseñas sin cifrar, e información personal de los empleados, se descubrieron en una base de datos de acceso público para una empresa utilizada por agentes de la policía metropolitana del Reino Unido, contratistas de defensa y bancos.

Suprema es la compañía de seguridad responsable del sistema de bloqueo biométrico Biostar 2 basado en la web que permite un control centralizado para el acceso a instalaciones seguras como almacenes o edificios de oficinas. Biostar 2 utiliza huellas dactilares y reconocimiento facial como parte de sus medios para identificar a las personas que intentan acceder a los edificios.

El mes pasado, Suprema anunció que su plataforma Biostar 2 estaba integrada en otro sistema de control de acceso: AEOS. AEOS es utilizado por 5.700 organizaciones en 83 países, incluidos gobiernos, bancos y la policía metropolitana del Reino Unido.

Los investigadores de seguridad israelíes Noam Rotem y Ran Locar que trabajan con VPNmentor, un servicio que revisa servicios de redes privadas virtuales, han estado ejecutando un proyecto paralelo para escanear puertos en busca de bloques de IP familiares, y luego usar estos bloques para encontrar agujeros en los sistemas de las empresas que potencialmente podría conducir a violaciones de datos.

En una búsqueda la semana pasada, los investigadores encontraron que la base de datos de Biostar 2 no estaba protegida y en su mayoría sin cifrar. Pudieron buscar en la base de datos manipulando los criterios de búsqueda de URL en Elasticsearch para obtener acceso a los datos.

Los investigadores tuvieron acceso a más de 27,8 millones de registros y 23 gigabytes de datos, incluidos paneles de administración, tableros, datos de huellas digitales, datos de reconocimiento facial, fotos faciales de usuarios, nombres de usuario y contraseñas sin cifrar, registros de acceso a las instalaciones, niveles de seguridad y autorización, y detalles personales del personal.

Gran parte de los nombres de usuario y contraseñas no estaban cifrados, dijo Rotem al Guardian. "El acceso permite en primer lugar ver que millones de usuarios están utilizando este sistema para acceder a diferentes ubicaciones y ver en tiempo real qué usuario ingresa a qué instalación o incluso a qué habitación. También pudimos cambiar los datos y agregar nuevos usuarios".

Esto significaría que podría editar la cuenta de un usuario existente y agregar su propia huella digital y luego poder acceder a cualquier edificio al que esté autorizado el usuario, o podría agregarse a sí mismo como usuario con su foto y huellas digitales.

En el documento sobre el descubrimiento, los investigadores dijeron que pudieron acceder a datos de organizaciones de trabajo conjunto en los EE. UU. E Indonesia, una cadena de gimnasios en India y Pakistán, un proveedor de medicamentos en Reino Unido, y un desarrollador de plazas de aparcamiento en Finlandia, entre otros.

Los investigadores dijeron que la magnitud de la violación fue alarmante porque el servicio se encuentra en 1,5 millones de ubicaciones en todo el mundo y porque, a diferencia de las contraseñas que se filtran, cuando se filtran las huellas dactilares, no se puede cambiar su huella digital.

"En lugar de guardar un hash de la huella digital (que no se puede aplicar ingeniería inversa) están guardando las huellas digitales reales de las personas que pueden copiarse con fines maliciosos", dijeron los investigadores en el documento.

Los investigadores hicieron múltiples intentos de contactar a Suprema antes de llegar al periódico a fines de la semana pasada. La madrugada del miércoles (hora australiana) la vulnerabilidad se cerró, pero aún no han recibido noticias de la empresa de seguridad.

El jefe de marketing de Suprema, Andy Ahn, le dijo a The Guardian que la compañía había realizado una "evaluación en profundidad" de la información proporcionada e informaría a los clientes si existía una amenaza.

Rotem dijo que el problema no era exclusivo de Suprema. "Es muy común. Hay literalmente millones de sistemas abiertos, y aunque atravesarlos es un proceso muy tedioso, algunos de los sistemas son bastante sensibles".

Dijo que las vulnerabilidades de la cadena de suministro, donde una compañía usa una compañía de terceros para un servicio que no tiene la seguridad adecuada, era común, pero a menudo algunas de las vulnerabilidades descubiertas se encontraban con compañías Fortune 500.

Rotem dijo que contacta a unas tres o cuatro compañías por semana con problemas similares. A principios de este año, Rotem señaló una falla sustancial en el sistema de reserva de vuelos de Amadeus."Los errores suceden, y la verdadera prueba es cómo los manejas. Si tiene un equipo de seguridad que puede responder rápida y eficientemente, es lo suficientemente bueno. Si tiene un equipo de seguridad que enviará un equipo legal para amenazarlo, bueno, es menos eficiente"

Fuente: The Guardian

Seguir leyendo...

Explotar Microsoft CTF de Windows XP a 10

Tavis Ormandy de Project Zero de Google ha publicado una vulnerabilidad de alta gravedad en MSCTF. La vulnerabilidad lleva sin parchear más de 20 años y afecta a todas las versiones de Microsoft Windows, desde Windows XP hasta el último Windows 10.

La vulnerabilidad reside en la forma en que los clientes y el servidor de MSCTF se comunican entre sí, lo que permite que incluso una aplicación de bajo privilegio o una zona protegida pueda leer y escribir datos en una aplicación de mayor privilegio.

MSCTF es un módulo en Text Services Framework (TSF) del sistema operativo Windows que administra cosas como métodos de entrada, diseños de teclado, procesamiento de texto y reconocimiento de voz.

En pocas palabras, cuando inicia sesión en su máquina Windows, inicia un servicio de monitor CTF que funciona como una autoridad central para manejar las comunicaciones entre todos los clientes, que en realidad son ventanas para cada proceso que se ejecuta en la misma sesión.

El problema está en el subsistema MSCTF que es parte del framework de servicios de texto o TSF (Text Service Framework). El TSF administra cosas como métodos de entrada, distribuciones de teclado, procesamiento de texto, etc.

Hay dos componentes principales, el servidor/monitor ctfmon y el cliente msctf. El servicio ctfmon arranca cuando se inicia sesión en la máquina como puedes comprobar simplemente viendo el administrador de tareas:

Este servicio crea un puerto ALPC (Local Inter-Process Communication) al que las aplicaciones se conectan para intercambiar mensajes sobre cambios en el layout del teclado o métodos de entrada. Cuando cualquier proceso crea una ventana, el kernel invoca una devolución de llamada o callback, USER32!CtfHookProcWorker, que carga automáticamente el cliente msctf.

El cliente se conecta al puerto ALPC y manda su HWND, el subproceso y la identificación del proceso.

El servidor espera continuamente los mensajes de los clientes, pero los clientes solo buscan mensajes cuando se les notifica a través de PostMessage(). Esta es la razón por la que los clientes llaman a RegisterWindowMessage() al inicio.

Los clientes pueden enviar comandos al monitor o pedirle al monitor que reenvíe comandos a otros clientes especificando el threat id, es decir, se pueden mandar mensajes a cualquier subproceso conectado, o al propio monitor configurando el destino en el subproceso cero. Además el protocolo CTF es bastante extenso, tiene muchos parámetros y hay fallos de diseño en este sistema. Tavis Ormandy ha creado una herramienta llamada CTFtool que nos permitirá interactuar como cliente desde la línea de comandos para experimentarlos.

Empezaremos conectándonos a nuestra sesión y viendo los clientes conectados:

¡No solo se puede enviar comandos al servidor, podemos esperar a que se conecte un cliente en particular y luego pedirle al servidor que también le envíe comandos! Además, como habéis podido imaginar, no hay un control de acceso entre los clientes y el servidor de MSCTF, lo que nos permitirá mandar comandos incluso a aplicaciones/clientes con privilegios elevados.

Y evidentemente tampoco vamos a conformarnos con cambiar una distribución de teclado para trollear... un protocolo tan antiguo como CTF tiene vulnerabilidades de corrupción de memoria y vamos a poder explotar un integer overflow para... por ejemplo, obtener una shell interactiva con privilegios de SYSTEM. "Sólo" hay que evadir CFG y ASLR y la magia ocurre...

A la caza del cliente CTF con privilegios

Ahora que sabemos que se puede comprometer a cualquier cliente CTF, ¿cómo encontramos algo útil? Como decimos, no hay control de acceso en CTF, por lo que podemos conectarnos a la sesión activa de otro usuario o esperar a que un Administrador inicie sesión y comprometer su sesión. Sin embargo, hay una mejor opción: si usamos USER32!LockWorkstation, podemos cambiar al escritorio Winlogon privilegiado que ya se está ejecutando como SYSTEM!:

O si quieres aprovecharte del cuadro de diálogo UAC con el correspondiente script sólo tienes que esperar y se iniciará la shell con privilegios (ver video):

Ahora a ver cómo Microsoft moderniza su protocolo CTF, porque esto y como dice Tavis, es sólo la punta del iceberg.

Fuente: HackPlayers

Seguir leyendo...

Quieren reducir los certificados HTTPS a 13 meses

Hace un año y medio aproximadamente redujeron el tiempo de vida útil de los certificados HTTPS. Pasaron de 39 meses a 27. Ahora pretenden reducir aún más el tiempo y que caduquen a los 13 meses. Esto significa reducir un poco más de la mitad su vida útil.

Con esto pretenden reducir el tiempo en el que podrían utilizar certificados que han sido robados. Esto podría dificultar el uso de páginas falsas y a su vez obligar a las empresas a utilizar algoritmos de cifrado que se renueven con una mayor frecuencia y que sean por tanto más fiables.

Puntos positivos pero también negativos de esta medida

Sin embargo hay debate entre los expertos en seguridad informática. Para algunos sí, esta medida podría mejorar la seguridad de las páginas webs y, en definitiva, hacer más segura la navegación de cara a los usuarios. Pero por otro lado están los que piensan que el hecho de reducir la vida útil de los certificados HTTPS no traerá una mejora significativa de seguridad.

En esta segunda postura, los que indican que realmente no traerá mejoras de seguridad, se basan en que los sitios webs maliciosos operan durante un tiempo muy corto. Esto significa que por mucho que restrinjamos el tiempo útil de los certificados a apenas 13 meses, esto sería más que suficiente para páginas fraudulentas.

Cuando una página web es detectada como una amenaza pasa a formar parte de una lista negra. Esto hace que el atacante se pase a otro dominio diferente y, a su vez, utilice certificados HTTPS distintos. Por mucho que estos certificados duren menos tiempo, igualmente los piratas informáticos van a cambiarlos con cierta frecuencia.

También alegan los costes evidentes de tener que asumir cambios de certificados más frecuentemente. Por ello el debate está abierto.

Respecto a cuándo entraría en vigor esta novedad de reducir la vida útil de los certificados HTTPS a 13 meses, habría que esperar hasta el próximo mes de marzo de 2020. A partir de esa fecha está previsto que los certificados HTTPS pasen de tener una duración de 27 meses a 13, algo menos de la mitad.

Fuente: Infosecurity

Seguir leyendo...