raspado de datos

All posts tagged raspado de datos

FSB-Rusia.jpg

Agencia Secreta Rusa sufre el mayor hackeo de su historia

La noticia salió el día de ayer. Hackers han atacado con éxito al FSB, la principal agencia de seguridad de Rusia. Los hackers lograron robar 7.5 terabytes de datos de un contratista importante, exponiendo proyectos secretos del FSB para 1) anular el anonimato de la navegación de Tor, 2) extracción de datos privados de las redes sociales, así como 3) ayudar al estado a separar su internet del resto del mundo. Los datos se pasaron a los principales medios de comunicación para su publicación.

El FSB es la principal agencia de seguridad de Rusia, similar al FBI de los EEUU y al MI5 del Reino Unido. Su competencia también se extiende más allá de la inteligencia nacional para incluir la vigilancia electrónica en el extranjero y una importante supervisión de recopilación de inteligencia. Es la principal agencia sucesora de la infame KGB, y reporta directamente al presidente de Rusia.

Hace una semana, el 13 de julio, un grupo de hackers con el nombre 0v1ru$ que supuestamente había violado a SyTech, un importante contratista de FSB que trabaja en una variedad de proyectos de Internet en vivo y exploratorios, dejó un Yoba Face sonriente en la página de inicio de SyTech junto con imágenes que pretenden mostrar el incumplimiento. 0v1ru$ pasó los datos al grupo de hackers Digital Revolution, que compartió los archivos con varios medios de comunicación y los titulares con Twitter.

La BBC edición Rusia dio la noticia de que 0v1ru$ había violado los servidores de SyTech y compartió detalles de proyectos cibernéticos polémicos, proyectos que incluían raspado de datos en redes sociales (incluidos Facebook y LinkedIn) , recopilación dirigida y la «desanonimización de los usuarios del navegador Tor«. La BBC describió la violación como posiblemente «la fuga de datos más grande en la historia de los servicios de inteligencia rusos«.

Dime algo que no sepa

Además de desfigurar la página de inicio de SyTech con Yoba Face, 0v1ru$ también detalló los nombres de los proyectos expuestos: «Arion», «Relation», «Hryvnia», junto con los nombres de los gerentes de proyectos de SyTech. El informe de la BBC afirma que no se expusieron secretos de estado.

Los proyectos en sí parecen ser una mezcla de raspado en redes sociales (Nautilus), recopilación dirigida contra usuarios de Internet que buscan anonimizar sus actividades (Nautilus-S), recopilación de datos dirigidos a empresas rusas (Mentor) y proyectos que parecen estar relacionados con los proyectos en curso de Rusia.

También se incluye una iniciativa para construir una opción para separar Internet interna de la red mundial (Hope and Tax-3). La BBC afirma que los proyectos de SyTech fueron en su mayoría contratados con la Unidad Militar 71330, parte de la 16ª Dirección del FSB que maneja inteligencia de señales, el mismo grupo acusado de enviar por correo electrónico software espía a los oficiales de inteligencia ucranianos en 2015.

Nautilus-S, el proyecto de desanonización de Tor, se lanzó realmente en 2012 bajo el mandato del Instituto de Investigación Kvant de Rusia, que está bajo el mandato del FSB. Rusia ha estado buscando formas de comprometer los nodos dentro de la estructura de Tor para prevenir comunicaciones fuera de la red o interceptar esas comunicaciones. Nada de lo cual es noticia nueva. Se cree que se han logrado algunos avances en este proyecto. Digital Revolution afirma haber hackeado el Instituto de Investigación Kvant antes.

Las actividades preparatorias para separar una «Internet rusa» siguen al acuerdo con el presidente ruso, Vladimir Putin, que firma las disposiciones para «el funcionamiento estable de la Internet rusa (Runet) en caso de que esté desconectado de la infraestructura global de la World Wide Web«. La ley establece planes de tren para un sistema de nombre de dominio (DNS) alternativo para Rusia en caso de que esté desconectado de la World Wide Web, o, se supone, en el caso de que sus políticos consideren que la desconexión es beneficiosa. Los proveedores de servicios de Internet se verían obligados a desconectarse de cualquier servidor extranjero, confiando en cambio en el DNS de Rusia.

No hay nada de interés periodístico en los proyectos expuestos aquí, todo fue conocido o esperado. El hecho de la violación en sí, su escala y aparente facilidad es lo de mayor importancia. Los contratistas siguen siendo el eslabón débil en la cadena de agencias de inteligencia de todo el mundo: para enfatizar el punto, la semana pasada, un ex contratista de la NSA fue encarcelado en los EEUU Por robar secretos durante dos décadas. Y las consecuencias de Edward Snowden continúan hasta el día de hoy.

Digital Revolution pasó la información a los periodistas sin que se editaran, eliminaron o modificaron nada, dijeron. Poco se sabe sobre 0v1ru $ y el grupo no ha hecho ningún comentario. Tampoco lo ha hecho la FSB.

Adaptación de un artículo publicado originalmente en .

leer más
Isaul CarballarAgencia Secreta Rusa sufre el mayor hackeo de su historia
Magecart-Blog-Header.jpg

Ataque de Magecart: qué es, cómo funciona y cómo evitarlo

Aprende cómo combatir este ataque de skimming de cartas basado en web.

Todos los días escuchamos sobre una nueva amenaza o vulnerabilidad en la tecnología, y el ataque de recolección de datos conocido como «Magecart» es la última amenaza. El siguiente texto es una transcripción de un entrevista entre Scott Matteson, escritor técnico de Techrepublic y Peter Blum, vicepresidente de tecnología del proveedor de entrega de aplicaciones Instart.

¿Qué es un ataque de Magecart?

Peter Blum: Magecart es una forma de raspado de datos (data skimming), que ataca con el uso del navegador del lado del cliente como la puerta de entrada a las interacciones del consumidor. «Skimming» es un método utilizado por los atacantes para capturar información confidencial de formularios de pago en línea, como direcciones de correo electrónico, contraseñas y números de tarjetas de crédito. Específicamente para Magecart, los piratas informáticos implantan códigos maliciosos en sitios web para robar información de tarjetas de crédito a medida que las personas ingresan las credenciales en la página de pago.

¿Cómo funciona el ataque Magecart?

Stealing a credit card through a laptop concept for computer hacker, network security and electronic banking security (Stealing a credit card through a laptop concept for computer hacker, network security and electronic banking security, ASCII, 118 co

los ataques de eliminación de datos como Magecart generalmente siguen un patrón bien establecido. Deben lograr tres cosas para tener éxito.

  • Paso 1: Acceso a su sitio web. Por lo general, hay dos formas en que los atacantes obtienen acceso a su sitio web y colocan el código de skimming. Pueden entrar en su infraestructura o en su servidor y colocar el skimmer allí. O, perseguirán a uno de sus proveedores externos, especialmente si son un objetivo más fácil e infectan una etiqueta de terceros que ejecutará un script malicioso en su sitio cuando se llame en el navegador.
  • Paso 2: Inspección superficial de información en un formulario. Hay muchas maneras diferentes en que los grupos pueden capturar datos, pero el código de limpieza es siempre una especie de JavaScript que escucha la información personal y la recopila. Hemos visto un enfoque en el que monitorean todas las pulsaciones de teclas en una página confidencial o algunas que interceptan entradas en partes específicas de un formulario web como los campos de tarjeta de crédito y CVV. En general, los atacantes esconden código malicioso dentro de otro código que parece benigno para evitar la detección.
  • Paso 3: Envío de información a su servidor. Esta es la parte más simple de todo el proceso. Una vez que los piratas informáticos obtienen acceso a su sitio web y raspan los datos que desean, se termina el juego. Pueden enviar la información de los navegadores de los usuarios finales a casi cualquier ubicación en Internet.

¿Quién está detrás de Magecart?

Magecart es el nombre que recibe esta categoría de ataques, no es una organización o entidad específica. Hay docenas de diferentes grupos criminales cibernéticos que utilizan este estilo de ataque. En el último año se produjeron ataques de alto perfil contra compañías como British Airways, Ticketmaster y NewEgg.

¿Qué vulnerabilidades / entornos se aprovechan?

Hoy en día, no es raro que un solo sitio web esté formado por un código creado y operado por hasta 50 compañías diferentes. El código que se desarrolla internamente y se ejecuta en su propio sitio web se llama código de primera persona. El código que proviene de otras compañías se llama código de tercero, cuarto o incluso de terceros.

Muchos clientes no saben que cuando integras código de otras compañías, en realidad tiene el mismo nivel de privilegio que tu propio código. Eso significa que este código externo puede mostrar mensajes a sus usuarios, eliminar datos confidenciales ingresados ​​por los usuarios o almacenados en cookies, o incluso redirigir al usuario a otro sitio.

En Instart , estamos viendo más y más sitios web en los que hasta el 75% de las llamadas realizadas por el navegador provienen de fuentes distintas a su compañía. Entonces, ¿cómo sabe realmente lo que sucede cuando los sitios web se basan en el código de 50 servicios en la nube diferentes, alojados en 50 organizaciones diferentes? Esta es la trampa en la que han caído muchos minoristas, y los atacantes de Magecart se aprovechan. Una vulnerabilidad en cualquier parte es una vulnerabilidad en todas partes.

La buena noticia es que puede proteger información confidencial. La clave es que todo este código solo se une cuando se ensambla en el navegador del consumidor. Por lo tanto, debe implementar una tecnología que pueda monitorear y proteger datos confidenciales en tiempo real en el navegador.

¿Qué deben hacer los departamentos de TI para combatir Magecart?

El problema con Magecart es que hay mucha confusión cuando se trata de proteger realmente estos ataques de raspado de tarjetas basados ​​en web. Por ejemplo, la auditoría de un sitio web sobre una base regular no se pueden detener los ataques, ya que el problema proviene de etiquetas de terceros que la auditoría no detectará.

Mi consejo para los equipos de TI es que adopten un enfoque de cero confianza con JavaScript en sus sitios, comenzando con una política para bloquear el acceso de forma predeterminada a cualquier información confidencial ingresada en formularios web y cookies almacenadas. A partir de ahí, solo permite un conjunto selecto de scripts vetados (generalmente solo los suyos) para acceder a datos confidenciales. Y como resultado, si este tipo de código de skimming llega a su sitio, simplemente no puede acceder a ninguna de la información confidencial.

Desafortunadamente, los navegadores web no proporcionan este tipo de funcionalidad, por lo que los equipos de TI deben implementar sus propios enfoques de protección o incorporar tecnología de proveedores externos que se especialicen en la protección contra este tipo de ataques.

¿Qué deben hacer los usuarios finales para hacer frente a esta amenaza?

Muchos consumidores confían en las tiendas en línea y en los sitios donde compran. Es mejor evitar los sitios web más pequeños que probablemente no tengan el mismo nivel de seguridad que las organizaciones más grandes y establecidas. Los usuarios finales deben asegurarse de mantener un registro de los cargos a sus tarjetas de crédito. Muchas veces se realizarán pequeños cargos de prueba para garantizar que el número de la tarjeta de crédito aún esté activo ante un fraude más generalizado. Los usuarios finales también deben considerar el uso de sistemas de pago como Apple Pay, que generan números únicos de cada transacción, lo que garantiza que, si los atacantes obtienen un número, no podrán reutilizarlo en el futuro. Y, finalmente, estos días los sistemas de supervisión de crédito se han convertido en una necesidad para garantizar que los datos personales no se aprovechen para abrir nuevas cuentas a su nombre.

¿Cómo es probable que esta amenaza evolucione?

Hemos visto incluso en el último año que este tipo de ataque se ha vuelto más común y evoluciona a un ritmo alarmante. Si bien los enfoques iniciales eran más fáciles de detectar, los delincuentes cibernéticos ahora ocultan su código malicioso a través de la codificación y la ofuscación en el interior de un código inofensivo, lo que hace que sea casi imposible revelar estos ataques mirando el código de terceros. Y ahora vemos que los piratas informáticos codifican la información robada antes de que se envíe desde el navegador para evadir los sistemas de detección de patrones que buscan números de tarjetas de crédito. El mejor enfoque es tomar un modelo de confianza cero y solo permitir que un código vetado muy específico acceda a información confidencial.

¿Cuáles son algunos pasos proactivos recomendados para administrar los ataques de Magecart en evolución?

La mejor defensa contra los ataques de Magecart es impedir el acceso. Las compañías en línea necesitan una solución que intercepte todas las llamadas API que su sitio web realiza al navegador y bloquea el acceso a datos confidenciales que no haya autorizado previamente. Esto evita que cualquier script malicioso, o cualquier script de terceros no crítico, obtenga acceso a la información que sus clientes ingresan en su sitio web. Este mismo sistema también debe tener un componente de monitoreo para alertar a las compañías cuando un tercero intente acceder a información confidencial.

Seguimos viendo un gran aumento en los ataques contra sitios web que toman y procesan información de pago de los usuarios finales. No solo estamos viendo ataques al estilo de Magecart como este robo de información directamente de los usuarios finales, sino también ataques sofisticados de bots que aprovechan las credenciales de usuario robadas y los números de tarjetas de crédito para cometer fraude al usar datos encontrados en otros sitios.

Es fundamental que las marcas piensen más allá e implementen una protección de seguridad web de extremo a extremo que pueda mitigar los ataques de Magecart en el navegador y proteger la infraestructura de back-end, al mismo tiempo que detiene los ataques sofisticados de redes de bots. Con el aumento masivo de servicios de terceros que se están utilizando, también vemos a terceros legítimos que capturan accidentalmente información confidencial de los usuarios, lo que puede exponer a las empresas a incumplir las regulaciones de la industria y del gobierno, incluidas PCI, HIPPA, GDPR y CCPA.

La entrevista original está disponible en el siguiente link.

leer más
Isaul CarballarAtaque de Magecart: qué es, cómo funciona y cómo evitarlo