Filtrado código fuente y credenciales de Scotiabank

Scotiabank fue criticado por su "nivel de seguridad" luego de que parte del código fuente interno, algunas credenciales de backend y aplicaciones móviles se vieron publicados abiertamente en GitHub durante meses.


Estos repositorios presentaban, entre otras cosas, diseño de software y claves de acceso para un sistema de tasa de cambio, código de una aplicación móvil y credenciales de inicio de sesión para servicios e instancias de bases de datos.

Jason Coulls, un profesional de TI, quien descubrió los datos que estaban expuestos, avisó a The Register, además de Scotiabank, GitHub y los procesadores de pagos y tarjetas integrados con el banco.

En las últimas 24 horas, el gigante financiero canadiense ha logrado bajar los repositorios de GitHub que, inadvertidamente había dejados abiertos al público. A continuación se muestra una captura de pantalla del código fuente filtrado.

<

Entre los cientos de archivos de documentación y código, que parecen haber sido creados por desarrolladores que trabajan en versiones de las aplicaciones móviles de Scotiabank para América Central y del Sur, se encuentra las credenciales para acceder a algunos de los sistemas y servicios de backend del banco repartidos por todo el mundo. Entre los diseños más sensibles estaban el código y los detalles del inicio de sesión para un sistema de base de datos SQL.


El códigos también incluye integración de los sistemas del banco con los servicios de pago, incluidos Samsung y Google Pay, así como los procesadores de tarjetas de crédito Visa y Mastercard, y otros.

Tener esta información pública puede haber dejado a Scotiabank y sus más de 25 millones de clientes totalmente abiertos a ataques, en caso de que el código sea analizado y se considere explotable. Ya en 2017 Coulls descubrió que la unidad de banca digital del gigante canadiense, supuestamente su rama de alta tecnología, no solo estaba usando certificados de seguridad que habían expirado cinco meses antes, sino que gran parte de su código no había sido auditado o depurado a fondo.

Según Coulls, este último error no es la primera vez que Scotiabank ha revelado sus secretos internos en línea. "En mi experiencia, esta seguridad de grado Muppet es perfectamente normal para Scotiabank, ya que generalmente filtran información una vez cada tres semanas en promedio", reflexionó Coulls.

"Scotiabank tenía instancias IBM AS/400 y DB2 en las que las credenciales y la información de conexión son públicas. Regularmente filtran el código fuente de todo, desde aplicaciones móviles orientadas al cliente hasta API REST del lado del servidor. También filtran datos de sus cliente. Si Alguna vez afirmó que la seguridad es una prioridad, me daría miedo ver cómo manejan las cosas de baja prioridad".

Fuente: The Register

Seguir leyendo...

Asegurar SWIFT mediante el uso de Cyber Kill Chain (II)

Por Vimal Mani, CISA, CISM, Six Sigma Black Belt

Como se vió en la primera parte, Cyber Kill Chain tiene las siguientes fases:

• Reconnaissance (Reconocimiento)
• Development of a cyberweapon (Desarrollo de un arma)
• Delivery of the cyberweapon (Entrega del arma)
• Exploitation and installation (Explotación e Instalación)
• Establishment of a command-and-control (C&C) center (Establecimiento de un Centro de Comando y Control)
• Achievement of the objectives (Logro de los objetivos)

Reconocimiento

Esta es la fase en la que los delincuentes informáticos recopilan diversos tipos de información sobre el objetivo y la infraestructura SWIFT del objetivo. La recopilación inicial de información se puede realizar mediante el estudio de objetivos a través de sitios web públicos, ingeniería social con empleados en las redes sociales y el uso de otra información disponible públicamente de varios foros.

También puede incluir técnicas como el escaneo de puertos que conectan la infraestructura SWIFT en busca de vulnerabilidades y servicios y aplicaciones que son vulnerables y pueden ser explotados. Esta fase puede tener lugar en el transcurso de algunas semanas, meses o incluso más de un año, dependiendo del tamaño del objetivo y sus medidas de protección de la información.

Desarrollo de un arma

En esta fase, los delincuentes analizan la información recopilada en la fase anterior para planificar el arma que se utilizará en el ataque. Esta arma se desarrolla en base al análisis de la información recopilada sobre el objetivo y la infraestructura de SWIFT. Por ejemplo, un atacante puede incrustar una payload entregable en un documento PDF o Word, o enviar una URL maliciosa que podría redirigir a los usuarios a un sitio cargado de malware.

Entrega del arma

Las herramientas desarrolladas generalmente se entregan al objetivo a través de publicidad maliciosa: correos electrónicos de phishing que tienen una URL maliciosa o archivos adjuntos. Las armas pueden guardarse en secreto en un sitio web, lo que permite ataques del tipo drive-by. La entrega de estas armas también puede ocurrir a través de una aplicación vulnerable (particularmente aplicaciones web), ataques de inyección SQL, XSS, etc. Estas armas incluso se pueden plantar fácilmente en un dispositivo USB u otro medio extraíble. Los dispositivos utilizados por el usuario siguen siendo los objetivos principales para la entrega de estas herramientas.

Explotación e Instalación

Un ataque comienza con la entrada de malware en los sistemas de información de la organización víctima. El malware puede ocultarse del escaneo de dispositivos de seguridad a través de una variedad de métodos, incluida la manipulación de los procesos de seguridad. Una vulnerabilidad existente en la infraestructura de SWIFT puede explotarse para enviar malware a la infraestructura de SWIFT a través de varios tipos de ataques, sin mucha dificultad.

Establecimiento de un Centro de Comando y Control (C&C)

Los atacantes configuran servidores dedicados de comando y control (C&C) para extraer los datos de la infraestructura SWIFT infectada o explotar la infraestructura para enviar mensajes SWIFT fraudulentos. Estos servidores de C&C usan técnicas de cifrado para ocultar sus pistas. Una vez que el malware se instala con éxito en el sistema de destino, los servidores de C&C controlados por delincuentes comienzan a comunicarse con el malware instalado. Esto les permite manipular de forma remota la infraestructura SWIFT comprometida para gestionar, mantener y evolucionar el ataque.

Logro de los objetivos

Después de comprometer el sistema, el primer trabajo de un atancate es encontrar servidores desprotegidos que contengan datos confidenciales y desprotegidos que se enviarán a los servidores de C&C establecidos previamente. Como objetivo, el delincuente podría incluso eliminar cualquier dato no protegido encontrado.

Esta imagen ilustra una cadena de actividades de Cyber ​​Kill involucradas en un ciberataque.

Deben abordarse múltiples áreas potenciales de riesgo de seguridad en cada fase de Cyber ​​Kill Chain, en relación con los ataques cibernéticos lanzados en la infraestructura SWIFT de una organización.

La imagen siguiente resume las diversas fases de la , el riesgo de seguridad involucrado y algunas medidas de mitigación de riesgos.

Para abordar de manera efectiva la gama de factores de riesgo de seguridad que involucran la infraestructura SWIFT, la SWIFT Corp global ha emitido un sólido conjunto de controles llamado SWIFT Customer Security Controls Framework, y ha ordenado su uso por la comunidad global de servicios bancarios y financieros a través de bancos centrales regionales que son los reguladores de regiones específicas.

Conclusión

Los recientes ataques han sacudido la fe en las medidas de seguridad tradicionales implementadas en organizaciones globales dentro y alrededor de la infraestructura de SWIFT. Por lo tanto, es una obligación ineludible que los directores de seguridad de la información (CISO) y los directores de información (CIO) echen un vistazo mucho más profundo a la cadena de ataques de Cyber ​​Kill dirigidos a SWIFT, e implementen controles de seguridad enfocado en varias capas y pensando en un enfoque de defensa en profundidad.

Esto ayudará a prevenir ataques en las fases avanzadas de la Cyber ​​Kill Chain, incluso si la fase anterior ha sido ejecutada con éxito por el delincuentes informático. Es muy importante mencionar que la empresa debe proporcionar todo el soporte requerido a los equipos de seguridad de la información y de TI para implementar y mantener una postura de seguridad efectiva en torno a la infraestructura SWIFT en la organización.

Nunca debe verse como una responsabilidad exclusiva de los equipos de TI y seguridad. Está claro que asegurar la infraestructura SWIFT de una organización es responsabilidad del negocio, habilitado por las funciones de seguridad de la información y TI.

Fuente: ISACA

Seguir leyendo...

Asegurar SWIFT mediante el uso de Cyber Kill Chain (I)

Por Vimal Mani, CISA, CISM, Six Sigma Black Belt

Los ataques cibernéticos están creciendo más rápido que nunca en todo el mundo. Los servicios bancarios y financieros se han convertido en objetivos preferidos para grupos de delincuentes informáticos notorios como Anonymous, Carbanak Group, Metel y GCMAN, 3 que atacan el sector de servicios bancarios y financieros de manera continua.

Después del golpe de alto perfil del Banco Central de Bangladesh4 en 2016, SWIFT se ha convertido en un objetivo preferido para muchos grupos de delincuentes globales. Incluso el famoso grupo Shadow Brokers anunció que ofrecía un servicio mensual de entrega de información basado en datos robados de proveedores de servicios SWIFT y bancos centrales de todo el mundo.

La Figura muestra la arquitectura típica de SWIFT en una organización financiera.

La falta de comprensión de las APT y la cadena de eventos es la causa principal

Muchos pueden decir que los firewall y la infraestructura de TI deficientes causaron el incidente de SWIFT en el Banco Central de Bangladesh. Pero el hecho es que los ataques SWIFT pueden ocurrir en cualquier organización de servicios bancarios y financieros, incluso en aquellos que cuentan con infraestructura de TI, soluciones de seguridad y centros de operaciones de seguridad (SOC) de última generación. Entonces, ¿cuál podría ser la verdadera causa de estos ataques dirigidos a la infraestructura SWIFT?

Un análisis de todos los últimos ataques cibernéticos dirigidos a la infraestructura SWIFT reveló la cadena de eventos que ocurrieron antes de la fase final del ataque, en la que se produjo la exfiltración de datos y/ola emisión de mensajes SWIFT ilegales. Estos eventos no ocurrieron en un solo día. Fueron bien planificados y ejecutados durante un período de tiempo. Estos eventos fueron impulsados ​​básicamente por malware bien estructurado llamado a Amenazas Avanzadas y Persistentes (APT).

En 2011, el Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST) definió un APT de la siguiente manera

Un adversario que posee niveles sofisticados de experiencia y recursos significativos que le permiten crear oportunidades para lograr sus objetivos mediante el uso de múltiples vectores de ataque (por ejemplo, cibernético, físico y engaño).

Estos objetivos generalmente incluyen el establecimiento y la ampliación de puntos de apoyo dentro de la infraestructura de TI de las organizaciones seleccionadas para fines de filtración de información; socavar o impedir aspectos críticos de una misión, programa u organización; o posicionarse para llevar a cabo estos objetivos en el futuro. Una amenaza persistente y avanzada: (i) persigue sus objetivos repetidamente durante un período prolongado de tiempo; (ii) se adapta a los esfuerzos de los defensores para resistirlo; y (iii) está decidido a mantener el nivel de interacción necesario para ejecutar sus objetivos.

Los APT se pueden describir como:

El malware Stuxnet que se utilizó en Irán, y el malware Slingshot, que se utilizó contra el sector de petróleo y gas en el Reino de Arabia Saudita, son ejemplos clásicos de APT que utilizan técnicas de ataque altamente complejas.

La cadena de actividades utilizadas por los APT se llama Cyber ​​Kill Chain.

Descripción general de Cyber ​​Kill Chain

La mayoría de los principales ataques cibernéticos observados en la historia reciente no fueron planificados y ejecutados en un solo día. Fueron bien pensados, planificados y ejecutados de manera sistemática durante un período de tiempo. Hay una serie de actividades involucradas en la planificación y ejecución de estos ataques cibernéticos: la Cyber ​​Kill Chain, un concepto inventado por Lockheed Martin.

Las fases clave de la cadena Cyber ​​Kill son:

• Reconnaissance (Reconocimiento)
• Development of a cyberweapon (Desarrollo de un arma)
• Delivery of the cyberweapon (Entrega del arma)
• Exploitation and installation (Explotación e Instalación)
• Establishment of a command-and-control (C&C) center (Establecimiento de un Centro de Comando y Control)
• Achievement of the objectives (Logro de los objetivos)

Parte II...

Fuente: ISACA

Seguir leyendo...

Investigadores revelan que se pueden secuestrar mensajes de Signal, Telegram y WhatsApp

Una nueva investigación revela un viejo problema: las aplicaciones de mensajería segura son tan seguras como el sistema en el que se ejecutan.

Las organizaciones de todos los tamaños han llegado a depender de aplicaciones de mensajería seguras como Signal, Telegram y WhatsApp bajo el supuesto de que el contenido confidencial que se comparte de esta manera seguirá siendo confidencial, una suposición destruida por una nueva investigación del Cisco Talos Intelligence Group.

Los investigadores de Talos han demostrado cómo los ataques de canal lateral de secuestro de sesión ponen a las aplicaciones de mensajería seguras, incluidas Signal, Telegram y WhatsApp, en riesgo de exponer por completo los mensajes del usuario. Vitor Venture, el líder técnico de Talos, afirma: "Si un atacante puede copiar los tokens de sesión de un usuario de escritorio, podrá secuestrar la sesión. El atacante no necesitará nada más que la información almacenada localmente."

Es importante destacar que no importa si esa información está realmente cifrada; copiar los datos permite al actor de amenazas crear una 'sesión de sombra' y se acabó el juego.

Aunque las metodologías y las consecuencias específicas varían entre las aplicaciones de mensajería mencionadas, los protocolos criptográficos que utilizan (MT Protocol or Signal Protocol) para el cifrado de extremo a extremo no pueden proteger los mensajes de los usuarios de los vectores de ataque a la interfaz de usuario.

Por ejemplo, el framework Electron, que utilizan tanto Signal como WhatsApp, podría tener una vulnerabilidad que conduzca a la ejecución remota de código y a la copia de mensajes. Además, está el hecho de que estas aplicaciones también se ejecutan en múltiples plataformas, incluidas las máquinas de escritorio. A principios de este año, Talos publicó un análisis del malware TeleGrab que secuestraba sesiones de Telegram mediante estas técnicas.

Los investigadores pensaron que se podían aplicar la misma técnica utilizada por TeleGrab contra las aplicaciones de mensajería, lamentablemente con gran éxito.

Entonces, ¿dónde deja esto a los usuarios comerciales de las llamadas aplicaciones de mensajería segura? ¿Deberían continuar usándolos, de hecho deberían estar usándolos para compartir información confidencial en primer lugar?

Wicus Ross, investigador principal de seguridad en SecureData Labs, recuerda que los exploits basados ​​en laboratorios no necesariamente se traducen en ataques del mundo real. "La mayoría de los ataques de canal lateral son ineficientes, caros y complejos en comparación con otros medios más convencionales. Hay formas más fáciles de extraer información de personas o dispositivos que tratar de filtrar datos aleatorios de un dispositivo".

Ron Masas, investigador de seguridad en Imperva, no está tan seguro. "Los ataques de canal lateral en sistemas que no son criptosistemas son probablemente la forma de ataque más ignorada que vemos hoy. La superficie de ataque es enorme y cuando se combina con la baja conciencia, tienes un problema real en tus manos. Si su sistema operativo se ve comprometido, hay pocas aplicaciones que se ejecuten en el sistema para evitar que el atacante obtenga datos confidenciales".

John Safa, fundador del proveedor de entrega de contenido seguro Pushfor, explicó que "Usar estas aplicaciones de mensajería para el consumidor en los negocios es muy riesgoso. La mayoría de las aplicaciones de mensajería tienen datos almacenados en servidores que no están bajo el control de los usuarios. El contenido compartido en plataformas de mensajería no está diseñado para compartir contenido de manera segura, por lo que se puede descargar al dispositivo, capturar o copiar".

Eso sin tener en cuenta el "pequeño" problema de que los ex empleados se llevan ese contenido con ellos y la "responsabilidad nula de los datos compartidos a través de una aplicación de mensajería para el consumidor porque no hay registro de si, qué contenido y cómo se comparte en las redes."

"El hecho de que se llame 'segura' a una aplicación no significa que el sistema en el que está instalado sea seguro", advierte Daniel Smith, investigador del Equipo de Respuesta a Emergencias de Radware.

¿Qué deberían hacer las plataformas seguras de mensajería para mitigar estas vulnerabilidades? ¿Hay demasiado énfasis en los protocolos criptográficos que protegen los datos en tránsito (y en reposo en sus propios servidores) a expensas de proteger el estado de la aplicación y la información del usuario delegando este proceso de seguridad en el sistema operativo?

"El cifrado de extremo a extremo ha elevado considerablemente la barra de seguridad: asegurar los datos en reposo también es una función importante cuando se busca la seguridad completa", dice Ed Williams, director de SpiderLabs de EMEA en Trustwave. "Una tercera parte de eso tiene que ser el usuario y ahora deben soportar parte de la carga de seguridad".

Como dice Williams, "la capacidad de usar un escritorio para ver mensajes es puramente por conveniencia, y sabemos que la seguridad y la conveniencia no siempre van de la mano..."

Fuente: SCMagazine

Seguir leyendo...

Botnet Emotet vuelve con correos infecciosos luego de 4 meses

Emotet, una de las botnets de propagación de malware más poderosas, está activa nuevamente después de una ausencia de cuatro meses, según varios investigadores de seguridad que notaron un aumento en la actividad principalmente contra objetivos estadounidenses, británicos y alemanes a partir del lunes.

El Departamento de Seguridad Nacional de EE.UU. clasifica a Emotet como una de las botnets de malware más costosas y destructivas jamás vistas. El último caso conocido de un ataque de Emotet a gran escala se informó en India en mayo, cuando un grupo de 8.000 intrusiones de botnets se dirigió a varias empresas.

En agosto, los investigadores de la firma de seguridad Cofense y Talos observaron que los servidores de comando y control que estaban asociados con Emotet se habían activado, aunque la propia botnet permaneció inactiva. A partir del lunes, sin embargo, una investigación adicional de varios analistas mostró que la red de bots estaba propagando código malicioso nuevamente, poniendo fin a una pausa desde mayo.

En una serie de twits, los investigadores de la firma de seguridad SpamHaus notaron que vieron una campaña de phishing asociada con Emotet el lunes, con la actividad dirigida a aquellos que hablan inglés, alemán, polaco o italiano.

Jason Meurer, ingeniero de Cofense, dice que cualquiera que esté detrás de la botnet Emotet comenzó a prepararse para este ataque a fines de agosto, con ajustes de código adicionales que comenzaron alrededor del 9 de septiembre. "El paso final fue comenzar a enviar los correos electrónicos armados", dijo Meurer a Information Security Media Group. "Esto ocurrió el 16 de septiembre y se originó a partir de bots en Alemania utilizando la táctica de la cadena de respuesta al principio. Rápidamente se extendió a otras regiones y comenzó a enviar correos electrónicos genéricos y de cadena de respuesta a gran escala".

Meurer señaló que aunque los EE.UU., Reino Unido y Alemania eran los principales objetivos de los correos electrónicos no deseados y de phishing, su empresa descubrió que muchos otros dominios en todo el mundo estaban siendo atacados a partir del lunes.

Según los investigadores, en el último ataque lanzado el lunes, la botnet está utilizando un método de cadena de respuesta para engañar a los usuarios. En este método, un correo electrónico de phishing parece una respuesta a una conversación anterior con un documento de Word adjunto, lo que significa que los usuarios pueden ser engañados fácilmente para descargar el documento o el enlace.

El documento enviado por los atacantes tiene un mensaje que solicita al usuario que acepte un acuerdo de licencia de Microsoft con un logotipo de Microsoft de aspecto genuino, según Cofense.
Una vez que se descarga el malware, Emotet usa el sistema infectado para enviar correos electrónicos de phishing adicionales y correo no deseado en un esfuerzo por hacer crecer la botnet, dicen los investigadores. Sin embargo, el objetivo final de la última campaña aún no está claro, señalan los investigadores.

"Comenzando a principios de este año, comenzamos a ver correos electrónicos que parecían tener contenido raspado al final del correo electrónico. En el caso de estos correos electrónicos, parece que el remitente y el receptor estuvieron en contacto anteriormente y que este correo electrónico es un seguimiento. Al hacer esto, los actores de Emotet pueden crear correos electrónicos tipo spear phishing que son relevantes y creíbles para el usuario final, lo que aumenta las probabilidades de que hagan clic".

Fuente: BankInfosecurity

Seguir leyendo...

Resolución 1523 (AR): Definición de Infraestructuras Críticas

De acuerdo a la Resolución 1523/2019 (18/09/2019), apruébese la Definición de Infraestructuras Críticas y de Infraestructuras Críticas de Información, la enumeración de los criterios de identificación y la determinación de los sectores alcanzados, que como Anexo I (IF-2019-78452510-APN-SGM#JGM) forma parte de la presente medida.

Apruébese el Glosario de Términos de Ciberseguridad, que como Anexo II (IF-2019-78455467-APN-SGM#JGM) forma parte de la presente medida.

 

Definición Infraestructuras Críticas

Las Infraestructuras Críticas son aquellas que resultan indispensables para el adecuado funcionamiento de los servicios esenciales de la sociedad, la salud, la seguridad, la defensa, el bienestar social, la economía y el funcionamiento efectivo del Estado, cuya destrucción o perturbación, total o parcial, los afecte y/o impacte significativamente.

Las Infraestructuras Críticas de Información son las tecnologías de información, operación y comunicación, así como la información asociada, que resultan vitales para el funcionamiento o la seguridad de las Infraestructuras Críticas.

Fuente: Boletín Oficial

Seguir leyendo...

Millones de datos médicos disponibles en Internet

Las imágenes médicas y los datos de salud de millones de estadounidenses, incluidas las radiografías, las resonancias magnéticas y las tomografías computarizadas, están sin protección en Internet y están disponibles para cualquier persona con conocimientos básicos de informática.

Según una investigación realizada por ProPublica y la emisora alemana Bayerischer Rundfunk, Los registros cubren más de 5 millones de pacientes en los EE.UU. y millones más en todo el mundo. En algunos casos, cualquiera podría utilizar programas gratuitos, o simplemente un navegador web para ver las imágenes y los datos privados

Se indentificaron 187 servidores que se utilizan para almacenar y recuperar datos médicos que no estaban protegidos a través de ninguna medida. Los servidores inseguros descubiertos se suman a una creciente lista de sistemas de registros médicos que se han visto comprometidos en los últimos años. A diferencia de algunas de las infracciones de seguridad recientes, en las que los delincuentes eludieron las defensas de la empresa, estos registros a menudo se almacenaban en servidores que carecían de las precauciones de seguridad que hace mucho tiempo se convirtieron en estándar para empresas y agencias gubernamentales.

"Ni siquiera se está hackeando algo, se entra por una puerta abierta", dijo Jackie Singh, investigador de ciberseguridad y director ejecutivo de la consultora Spyglass Security. Algunos proveedores médicos comenzaron a bloquear sus sistemas después de que les contáramos lo que habíamos encontrado.

Nuestra revisión encontró que el alcance de la exposición varía, dependiendo del proveedor de salud y del software que usan. Por ejemplo, el servidor de la compañía estadounidense MobilexUSA mostró los nombres de más de un millón de pacientes, todo escribiendo una simple consulta de datos. También se incluyeron sus fechas de nacimiento, médicos y procedimientos.

Alertado por ProPublica, MobilexUSA reforzó su seguridad la semana pasada. La compañía toma radiografías móviles y brinda servicios de imágenes a hogares de ancianos, hospitales de rehabilitación, agencias de hospicio y prisiones. "Atenuamos rápidamente las posibles vulnerabilidades identificadas por ProPublica e inmediatamente comenzamos una investigación exhaustiva y continua", dijo la compañía matriz de MobilexUSA en un comunicado.

Otro sistema de imágenes, vinculado a un médico en Los Ángeles, permitió a cualquier persona en Internet ver los ecocardiogramas de sus pacientes.

En total, los datos médicos de más de 16 millones de escaneos en todo el mundo estaban disponibles en línea, incluidos nombres, fechas de nacimiento y, en algunos casos, números de la Seguridad Social.

Los expertos dicen que es difícil determinar quién es el culpable de no proteger la privacidad de las imágenes médicas. Según la ley de EE.UU., los proveedores de atención médica y sus socios comerciales son legalmente responsables de garantizar la privacidad de los datos del paciente. Varios expertos dijeron que tal exposición de los datos del paciente podría violar la Ley de Responsabilidad y Portabilidad del Seguro de Salud, o HIPAA, la ley de 1996 que exige que los proveedores de atención médica mantengan la confidencialidad y seguridad de los datos de salud de los estadounidenses.

Aunque ProPublica no encontró evidencia de que los datos de los pacientes se copiaron de estos sistemas y se publicaron en otros lugares, las consecuencias del acceso no autorizado a dicha información podrían ser devastadoras. "Los registros médicos son una de las áreas más importantes para la privacidad porque son muy sensibles. El conocimiento médico se puede usar en su contra de manera maliciosa: para avergonzar a las personas, para chantajear a las personas", dijo Cooper Quintin, investigador de seguridad y tecnólogo superior del personal de Electronic Frontier Foundation, un grupo de derechos digitales. "Esto es tan irresponsable", dijo.

El tema no debería sorprender a los proveedores médicos. Durante años, un experto ha tratado de advertir sobre el manejo casual de los datos personales de salud. Oleg Pianykh, director de análisis médico del departamento de radiología del Hospital General de Massachusetts, dijo que el software de imágenes médicas se ha escrito tradicionalmente con el supuesto de que los sistemas de seguridad informática del cliente protegerían los datos de los pacientes.

Pero a medida que esas redes en hospitales y centros médicos se volvieron más complejas y se conectaron a Internet, la responsabilidad de la seguridad pasó a los administradores de red que asumieron que existían salvaguardas. "De repente, la seguridad médica se ha convertido en un proyecto de bricolaje", escribió Pianykh en un artículo de investigación de 2016 que publicó en una revista médica.

La investigación de ProPublica se basó en los hallazgos de Greenbone Networks, una empresa de seguridad con sede en Alemania que identificó problemas en al menos 52 países en todos los continentes habitados. Dirk Schrader de Greenbone primero compartió su investigación con Bayerischer Rundfunk después de descubrir que los registros de salud de algunos pacientes estaban en riesgo. Los periodistas alemanes luego se acercaron a ProPublica para explorar el alcance de la exposición en los EE.UU.

Schrader encontró cinco servidores en Alemania y 187 en los EE.UU. que pusieron a disposición los registros de los pacientes sin una contraseña. ProPublica y Bayerischer Rundfunk también escanearon direcciones, cuando fue posible, a qué proveedor médico pertenecían.

ProPublica determinó de forma independiente cuántos pacientes podrían verse afectados en Estados Unidos y descubrió que algunos servidores ejecutaban sistemas operativos obsoletos con vulnerabilidades de seguridad conocidas. Schrader dijo que los datos de más de 13.7 millones de exámenes médicos en los EE.UU. estaban disponibles en línea, incluidos más de 400.000 en los que se podían descargar rayos X y otras imágenes.

Fuente: ProPublica

Seguir leyendo...

Nueva lista de vulnerabilidad comunes (MITRE CWE Top 25)

Los 25 errores de software más peligrosos de Common Weakness Enumeration (CWE Top 25) desarrollado por MITRE es una lista demostrativa de las debilidades más extendidas y críticas que pueden conducir a serias vulnerabilidades en el software. Estas debilidades son a menudo fáciles de encontrar y explotar. Son peligrosos porque con frecuencia permiten a los adversarios tomar control completo de servicios, robar datos o evitar que el software funcione.

El CWE Top 25 es un recurso que puede ser utilizado por desarrolladores, clientes, gerentes de proyectos, investigadores de seguridad y educadores para proporcionar información sobre algunas de las amenazas de seguridad más frecuentes en la industria del software.

Para crear la nueva lista de 2019, el equipo de CWE utilizó un enfoque basado en datos que aprovecha los datos publicados de ed Common Vulnerabilities and Exposures (CVE) y las asignaciones de CWE National Vulnerability Database (NVD) de NIST y Common Vulnerability Scoring System (CVSS) asociados con cada uno de los CVE. Luego se aplicó una fórmula de puntuación para determinar el nivel de prevalencia y peligro que presenta cada debilidad. Este enfoque basado en datos se puede utilizar como un proceso repetible y con secuencias de comandos para generar una lista CWE Top 25 de forma regular con un mínimo esfuerzo.

Rank	ID	Nombre	Score
[1]	CWE-119	Improper Restriction of Operations within the Bounds of a Memory Buffer	75.56
[2]	CWE-79	Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')	45.69
[3]	CWE-20	Improper Input Validation	43.61
[4]	CWE-200	Information Exposure	32.12
[5]	CWE-125	Out-of-bounds Read	26.53
[6]	CWE-89	Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')	24.54
[7]	CWE-416	Use After Free	17.94
[8]	CWE-190	Integer Overflow or Wraparound	17.35
[9]	CWE-352	Cross-Site Request Forgery (CSRF)	15.54
[10]	CWE-22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')	14.10
[11]	CWE-78	Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')	11.47
[12]	CWE-787	Out-of-bounds Write	11.08
[13]	CWE-287	Improper Authentication	10.78
[14]	CWE-476	NULL Pointer Dereference	9.74
[15]	CWE-732	Incorrect Permission Assignment for Critical Resource	6.33
[16]	CWE-434	Unrestricted Upload of File with Dangerous Type	5.50
[17]	CWE-611	Improper Restriction of XML External Entity Reference	5.48
[18]	CWE-94	Improper Control of Generation of Code ('Code Injection')	5.36
[19]	CWE-798	Use of Hard-coded Credentials	5.12
[20]	CWE-400	Uncontrolled Resource Consumption	5.04
[21]	CWE-772	Missing Release of Resource after Effective Lifetime	5.04
[22]	CWE-426	Untrusted Search Path	4.40
[23]	CWE-502	Deserialization of Untrusted Data	4.30
[24]	CWE-269	Improper Privilege Management	4.23
[25]	CWE-295	Improper Certificate Validation	4.06

Fuente: MITRE

Seguir leyendo...

Filtración masiva de datos de ciudadanos en Ecuador

Ecuador tiene menos de 17 millones de habitantes y, según una firma de seguridad, la mayoría de los datos personales de casi todos ellos han sido expuestos.

La compañía de seguridad informática vpnMentor aseguró en un informe que dos de sus expertos detectaron a inicios de septiembre que un servidor utilizado por una empresa de análisis de datos y que contenía información personal sobre millones de ecuatorianos no contaba con los protocolos de protección necesarios.

Y, por lo tanto, casi cualquier persona podía acceder a ellos. El gobierno de Ecuador no confirmó de inmediato la filtración, aunque indicó que está investigando lo sucedido y recopilando información al respecto.

"Desde primeras horas de la mañana, el gobierno ecuatoriano realiza una investigación para levantar toda la información y descubrir qué ha sucedido y quiénes son los responsables", indicó una fuente oficial a BBC News Mundo.

De confirmarse de forma oficial, sería la mayor filtración en línea de información personal en la historia del país sudamericano y una de las mayores en Latinoamérica, dado el número de personas expuestas.

¿Qué se sabe de la filtración?

De acuerdo con vpnMentor, la filtración ocurrió desde un servidor en Miami que no contaba con los requisitos de seguridad establecidos y que era administrado por Novaestrat, una empresa ecuatoriana de marketing y análisis.

Se trata de 18 GB de datos distribuidos en una variedad de archivos y que incluía nombres, información financiera y datos civiles de hasta 20 millones de personas.

"La filtración abarca una gran cantidad de información personal confidencial (...) La mayoría de los individuos afectados parecen estar ubicados en Ecuador", señala la firma en un comunicado en su página web.

Tras el comunicado de vpnMentor, el acceso al servidor fue restringido por el equipo de seguridad informática de emergencia de Ecuador.

Novaestrat no respondió de forma inmediata a las preguntas de la BBC.
¿Qué información reveló la filtración?Además de los datos de identidad básicos, los archivos expuestos incluían:

• números oficiales de identificación del gobierno
• números de teléfono
• registros familiares
• fechas de matrimonio
• historias educativas
• registros de trabajo

El caché de información también incluía algunos registros financieros que contaban los saldos de las cuentas de los clientes de un gran banco ecuatoriano, según la firma de seguridad informática.
Mientras, los registros de impuestos, incluidos los números de identificación de ingresos oficiales de las empresas, se encontraron en otro archivo.

¿Cuán grave es la filtración?

Según vpnMentor, se trata de una falla informática "particularmente grave", dado el tipo y la cantidad de información que se reveló sobre cada individuo.
"La violación de datos implica una gran cantidad de información sensible de identificación personal a nivel individual", escribieron Noam Rotem y Ran Locar, los expertos que encontraron la falla.

La noticia sobre la violación de datos fue revelada en el sitio web de ZDNet, quien consideró que esa información podría ser "tan valiosa como el oro en manos de bandas criminales".

Las búsquedas simples revelaban listas de ecuatorianos ricos, sus domicilios, si tenían hijos, los autos que conducían y sus números de matrícula, indicó el portal de tecnología.

"Esto pone a las personas en riesgo de robo de identidad y fraude financiero. Una parte maliciosa con acceso a los datos filtrados posiblemente podría reunir suficiente información para obtener acceso a cuentas bancarias y más", consideró vpnMentor.

La empresa informática estimó además que el acceso a detalles sobre los carros puede ayudar a los delincuentes a identificar vehículos específicos y la dirección de su propietario.

"Este tipo de violación de datos podría haberse evitado con algunas medidas de seguridad básicas", consideró el portal tecnológico.

¿Cómo se descubrió?

La agencia de seguridad informática indicó que descubrió la filtración como parte de un proyecto de mapeo web a gran escala.
Los expertos de vpnMentor escanean puertos IP y luego buscan vulnerabilidades en el sistema que indiquen una base de datos abierta.

Fue así como encontraron que un servidor en Miami contenía información en la nube de millones de personas.
La compañía indicó que, como parte de su práctica, tras detectar la filtración, contactaron el propietario del servidor y le informaron sobre la vulnerabilidad.

¿Aún es riesgosa la fuga?

Desafortunadamente, sí. Según vpnMentor, una vez que los datos se han expuesto, la filtración no se puede deshacer.

Esto implica que, aunque actualmente no se puede acceder a la base de datos del servidor, la información podría estar ya en manos de partes malintencionadas.

Según el reporte, la filtración también podría tener un impacto en empresas ecuatorianas, ya que los datos filtrados incluían información sobre empleados, así como detalles sobre algunas compañías.

"Estas compañías pueden estar en riesgo de espionaje comercial y fraude. El conocimiento de los empleados de una empresa podría ayudar a los competidores u otras partes maliciosas a recopilar datos confidenciales adicionales de la empresa", indicó vpnMentor.

Fuente: BBC

Seguir leyendo...

OWASP Serverless Security Top 10

El proyecto OWASP Serverless Top 10 tiene como objetivo educar a profesionales y organizaciones sobre las vulnerabilidades de seguridad de aplicaciones tipo serverless más comunes y proporcionar técnicas básicas para identificarlas y protegerlas.

Las arquitecturas sin servidor son diseños de aplicaciones que incorporan servicios "Backend as a Service" (BaaS) de terceros y/o que incluyen código personalizado ejecutado en contenedores administrados y efímeros en una plataforma de "Funciones como servicio" (FaaS). Al utilizar estas ideas y otras relacionadas, como las aplicaciones de una sola página, tales arquitecturas eliminan gran parte de la necesidad de un componente de servidor tradicional siempre activo. Las arquitecturas sin servidor pueden beneficiarse de un costo operativo significativamente reducido, complejidad y tiempo de entrega de ingeniería, a un costo de mayor dependencia de las dependencias del proveedor y servicios de soporte relativamente inmaduros.

Al adoptar la tecnología sin servidor, eliminamos la necesidad de instalar un servidor para administrar nuestra aplicación. Al hacerlo, también pasamos algunas de las amenazas de seguridad al proveedor de infraestructura como AWS, Azure y Google Cloud. Además de las muchas ventajas del desarrollo de aplicaciones sin servidor, como el costo y la escalabilidad, algunos aspectos de seguridad también se entregan a nuestro proveedor de servicios. Los servicios sin servidor ejecutan código sin aprovisionar o administrar servidores y el código se ejecuta solo cuando es necesario.

Sin embargo, incluso si estas aplicaciones se ejecutan sin un servidor administrado, aún ejecutan código. Si este código está escrito de manera insegura, aún puede ser vulnerable a los ataques a nivel de aplicación. Los servicios serverless como ​AWS Lambda​, ​Azure Functions​, ​Google Cloud Functions y ​IBM Cloud Functions​, ejecutan código para aprovisionar servidores.

Este top 10 examina las diferencias en los vectores de ataque, las debilidades de seguridad y el impacto comercial de los ataques de aplicaciones en el mundo sin servidor y, lo más importante, el informe recomienda formas de prevenirlos. Como podemos ver en el documento, las técnicas de ataque y defensa son diferentes de las que solíamos usar en el mundo de las aplicaciones tradicionales.

Tabla de contenidos

• Release notes
• Intro: Welcome to Serverless Security
• A1:2017 Injection
• A2:2017 Broken Authentication
• A3:2017 Sensitive Data Exposure
• A4:2017 XML External Entities (XXE)
• A5:2017 Broken Access Control
• A6:2017 Security Misconfiguration
• A7:2017 Cross-Site Scripting (XSS)
• A8:2017 Insecure Deserialization
• A9:2017 Using Components with Known Vulnerabilities
• A10:2017 Insufficient Logging and Monitoring
• Other Risks to Consider
• Summary
• Future Work
• Acknowledgements

Fuente: OWASP

Seguir leyendo...