Search Results for: cloud

Seguridad en Cloud computing

10 de septiembre de 2010 Por

He decidido poner el término Cloud computing en el titulo del post para tener mas visitas, ya que es un termino de moda, pero si me disculpan la pequeña “trampa”, en su lugar voy a hablar de la seguridad en Infraestructuras compartidas, que es un tema tanto o más interesante en seguridad.

Cuando hablamos de Infraestructuras compartidas nos referimos a la serie de infraestructuras TI que en cualquier organización son compartidas por diversos proyectos. Por ejemplo es habitual que se comparta la infraestructura de red, el almacenamiento en una cabina de discos, o los mismos servidores físicos mediante virtualización; si es un proveedor de servicios el que ofrece la infraestructura, estos elementos estarán compartidos además entre diversos clientes que en si mismo son organizaciones diferentes (vamos, el servicio de hosting de toda la vida).

Así pues, vamos a comentar diversas vulnerabilidades que con las medidas adecuadas están contempladas y en teoría resueltas, pero que son en todo caso posibles vulnerabilidades que pueden aparecer cuando se comparten infraestructuras.

Infraestructura de red compartida: No es difícil imaginar un escenario donde tenemos varios servidores conectados a la misma infraestructura de red, donde, si todo se configura bien no deberían haber problemas, pero si se configura mal, pueden pasar entre otras las siguientes cosas: (1)

  • Sniffing: Un equipo puede ver el trafico del equipo de al lado; esto puede pasar si están conectados al mismo switch y no se han tomado las necesarias precauciones (arp posisoning).
  • DOS: Al estar un equipo próximo a otro, puede atacarlo con un gran ancho de banda o un gran numero de conexiones.
  • Interceptar/sustituir: Es posible que un equipo pueda suplantar a otro (p.e. cambiando la IP) para interceptar el trafico o suplantar respuestas.
  • Atacar: Es posible que al compartir una misma infraestructura de red, desde dentro de la misma red (por ejemplo dentro de la misma DMZ) los equipos puedan atacar a los otros, teniendo mas visibilidad de servicios que desde el exterior están cerrados. Una descripción de cómo hacer esto pueden encontrarla aquí.

¿Están las infraestructuras de red compartidas convenientemente independizadas en los servicios de hosting y de Cloud?

Infraestructura de disco compartida: En cualquier infraestructura TI, es habitual que se disponga de una cabina de disco (SAN/NAS) a la que se conectan todos los servidores (desde servidores internos, hasta servidores de la DMZ)(2)

  • Acceso a datos (no autorizados): Técnicamente es posible que un servidor se conecte al disco de otro servidor si comparte cabina, con lo que podría leer o incluso alterar los datos. Las cabinas de disco normalmente limitan qué servidor puede conectar a qué parte de disco, basándose en la direccion “MAC” (se llama WWN) de la tarjeta. ¿Podría un hacker cambiar esa dirección? ¿Tenemos hard-zoning para evitar este ataque? Aun no he visto ninguna instalación en que se configure hard-zoning ya que es bastante mas incómodo. Si piensa que es muy raro que todos los servidores tengan acceso a los mismos discos, piense en todos sus servidores host de virtualizacion que pueden acceder a todos los discos del cluster.
  • DOS/Carga: ¿Qué pasa si un servidor monopoliza todos los recursos?
  • Acceso a datos borrados: ¿Qué pasa si montamos una unidad de disco en el servidor de un cliente y luego la conectamos a otro servidor de otro cliente? ¿Si leemos el disco vemos los datos del otro cliente? Muchos me diréis que es una posibilidad muy extraña ya que las cabinas de discos limpian las LUNs antes de asignarlas, pero esto “se le paso” a Amazon Ec2.

¿Están las infraestructuras de almacenamiento convenientemente independizadas en los servicios de hosting y de Cloud? (3)

  • Virtualización: Cualquier entorno TI de hoy en día dispone de servidores virtualizados, ya que es una de la manera mas efectivas de compartir recursos, garantizar la disponibilidad, ahorrar energía y muchas otras cosas. Numerosos sistemas Cloud (IAAS) están basados fundamentalmente en sistemas virtualizados, con APIs de autoprovisionamiento. Veamos algunos de los ataques que se pueden realizar en este tipo de entornos.
    • Ataques de guest a host: Ya han aparecido vulnerabilidades mediante las cuales un guest ha podido ejecutar código en el espacio del host, y por lo tanto desde un servidor virtual es posible atacar a otras maquinas virtuales. Véase este enlace para más detalles.
    • Consolas remotas compartidas (el “control panel” del cloud): Si tenemos un sistema de virtualización compartido, al cual accedemos desde una consola de gestión remota a través de Internet, ¿qué pasa si esta consola de gestión tiene alguna vulnerabilidad y alguien coge el control? Pueden haber muchos posibles problemas, desde vulnerabilidades de la aplicación de gestión remota (XSS para robo de sesión sería un ataque viable) a posibles pérdidas de credenciales. La autenticación de estos sistemas por ahora es simple y sin dispositivos robustos. Otro vector de ataque pueden ser las APIs de gestión de ofrecidas por los servicios de cloud, ya que mediante estas APIs se pueden crear o destruir servidores; ¿seguro que no hay vulnerabilidades mediante las cuales se puedan crear o destruir servidores de otro cliente?
    • Carga/DOS/QOS: ¿Qué pasa si un cliente monopoliza todos los recursos?
    • Vulnerabilidades del host (desde fuera, o desde los guests): El host es otro sistema que puede ser atacado, bien desde donde sea accesible (consola de gestión p.e.) o bien desde los propios guest que debido a alguna vulnerabilidad son capaces de coger control de host. Dicho de otra forma, aunque uno pueda tener su servidor web y sus aplicativos securizados, quizá el host que los alberga no lo está.
  • Servidores web/servidores de aplicaciones compartidos: Es habitual compartir el mismo servidor de aplicaciones entre diversos proyectos, pero hay que contemplar los problemas que nos podemos encontrar:(4)
    • Tienen acceso al mismo almacenamiento.
    • Son el mismo usuario de maquina/BBDD/memoria.
    • QOS: Puede un usuario degradar el rendimiento de todos los usuarios.

    Un ejemplo de estos servicios en la nube son: Windows azure o Google Application Engine.

¿Están las infraestructuras de virtualización convenientemente independizadas en los servicios de hosting y de Cloud?

Hosting/Aplicaciones SAAS compartidas: Dentro de lo que está tan de moda del cloud, también se incluyen de alguna manera las aplicaciones compartidas modelo cloud (SAAS). En el fondo, éste es el modelo mas antiguo de hosting, en el que las aplicaciones originales eran servidores web, servidores de correo compartidos entre diversos clientes. Hoy en día se ofrecen aplicaciones mas elaboradas que ofrecen más valor a las organizaciones. Veamos qué problemas nos podemos encontrar en estos modelos.

Imagínese que comparte aplicación entre “perfiles” o clientes. Es posible que dos usuarios de la misma aplicación, por algún error de diseño de ésta, tengan acceso a lectura o modificación de otro usuario. Por ejemplo, recordarán que hace poco sucedió que un usuario de facebook podía ver cualquier conversación del chat de otro. Así pues, si usamos de manera compartida una “aplicación” SAAS, nos podemos encontrar con posibles problemas si no ésta no está bien implementada. ¿Podría pasar que en nuestro CRM en SAAS por un error de programación pudiéramos ver los clientes de otra empresa también albergada en este SAAS? Facebook tuvo una vulnerabilidad con la que podías ver los chats de otros usuarios.

¿Están las aplicaciones convenientemente independizadas en los servicios de hosting y de Cloud? (5)

Mira por dónde, sin quererlo, he acabado hablando de Cloud Computing, nada nuevo respecto a lo que ya conocemos en cuanto a infraestructuras compartidas, pero sin duda una novedad en cuanto a que está todo junto, con las ventajas que esto aporta, pero con el añadido que hay que considerarlo todo conjuntamente.

Por repasar los tipos de Cloud existentes:

  • IAAS, Infraestructure as a service: básicamente podríamos decir que tenemos una macroplataforma virtualizada bajo demanda (1)(2)(3).
  • PAAS, Platform as a Service: tenemos una especie de servidor de aplicaciones distribuido y autoescalable (4).
  • SAAS, Software as a Service: tenemos una aplicación general la cual nos da servicio (5).

En este post hemos revisado algunas vulnerabilidades desde un punto de vista técnico que aparecen si compartimos infraestructuras. Desde el punto de vista de control sobre los servicios externalizados y concentrados en datacenters de megacorporaciones también hay mucho que hablar, y por otro lado los proveedores de sistemas virtuales están redefiniendo sus productos haciendo que cada vez se parezcan mas a una nube “privada” en cuanto a que se dispone de unas infraestructuras compartidas autogestionadas. Todas la posibles vulnerabilidades mencionadas sólo son posibles puntos de fallo por donde aparecerán vulnerabilidades, que aunque en principio ya están contempladas y cubiertas, debemos contar que irán apareciendo nuevas vulnerabilidades causadas por compartir infraestructura. Si dicha infraestructura es sólo compartida entre proyectos internos de la organización los riesgos son unos, pero si la infraestructura es compartida con no sabemos quién, y disponible en Internet los riesgos son mayores. Esto es lo que hay que saber valorar.

A pesar de ello, los servicios en Cloud son la evolución lógica de hosting (infraestructuras compartidas de toda la vida). Todo lo que tuviera sentido en ese entorno ahora lo puede tener en la nube; en todo caso los proyectos que necesitan una grandísima escalabilidad normalmente están asociados a accesos desde Internet, en cuyo caso la nube tiene todo el sentido del mundo, ya que nos permite acceder a proveedores con grandes capacidades de almacenamiento, ancho de banda y servidores. Es más, me atrevería a apostar que los proveedores serios de Cloud sí tienen en mente que todos los recursos compartidos deben estar independizados, y probablemente sean más conscientes de estos riesgos que los provedores de hosting más tradicionales, con aproximaciones más “ligeras” al Cloud.

Dicho esto, pasen un buen fin de semana, y ¡¡nos vemos en la nube!!

¿Qué pasa con la Seguridad y el Cloud Computing?

24 de mayo de 2010 Por

Algunos tuvimos la oportunidad de celebrar el pasado día mundial de Internet con una mesa redonda sobre Cloud Computing en la que participaron ocho personalidades de distintas multinacionales, de las que solo una de ellas era española. La mesa redonda estuvo moderada por la Consejera de Justicia y Administraciones Públicas de la Generalitat Valenciana y la verdad es que fue bastante interesante, e incluso yo diría que pertinente y adecuada en los tiempos que corren, tanto por la forma, como por el fondo.

Cloud es una moda. Todos estaban de acuerdo en que ya no es una utopía. Es una realidad, pero una realidad de moda. También parecían estar todos de acuerdo que una de las grandes ventajas que tiene este nuevo paradigma (así lo presentan algunos) es la reducción de costes. “Es una nueva forma de hacer outsourcing en un entorno global y virtual”, decían algunos. “Es una forma clara de reducir costes e incluso de incrementar la productividad”, decían otros. La verdad es que en medio de todas estas afirmaciones, vertidas incluso en ocasiones con pasión, yo me preguntaba si no será este otro de esos conceptos que usan las grandes firmas para seguir haciendo negocio con cosas que el resto de los mortales no acaban de entender.

En mi humilde opinión Cloud Computing es un concepto muy interesante que seguro ya tiene y tendrá aplicaciones en diversos campos, ahora bien, la solución a todos los problemas no es el Cloud Computing, ni siquiera es un modelo de gestión o una tecnología disruptiva equivalente, como algunos defienden, a la aparición de Internet. Para empezar, porque es un modelo que ya funciona en la red desde hace tiempo y porque lo único que se ha hecho es bautizarlo con un nombre pegadizo que estoy seguro moverá cifras millonarias en los próximos años.

Se habla de la consolidación de unos cuantos Data Centers gigantes a nivel mundial como proveedores de servicios en la nube y su connivencia con unos cuantos operadores y algunos proveedores de aplicaciones en la misma nube. Se habla del traslado de cantidades ingentes de información a la nube, de información de todo tipo y color, se habla de los inmensos beneficios que le puede suponer para una empresa de tamaño medio hacer uso de este modelo, e incluso, alguno se atreve a poner un ejemplo dónde los ahorros de costes superan el 50%, citando incluso la organización en cuestión.

Yo no sé si esto será exacto o si será una “realidad aumentada”, pero ¿alguien se ha parado a pensar lo que realmente significa esto? ¿Alguien se ha parado a pensar en las implicaciones de seguridad que puede tener el traslado indiscriminado del conocimiento de las organizaciones de todo tipo a la nube? ¿Alguien se ha parado a pensar en el riesgo de la concentración de activos y conocimiento para una compañía o para un estado? Si a veces no pueden las organizaciones confiar en sus propios equipos, ¿por qué van a hacerlo en los equipos de terceros de forma masiva e indiscriminada? ¿No creen ustedes que aunque este modelo tiene y va a tener sentido para algún tipo de aplicaciones e información no lo puede tener nunca para otro?

Yo creo que como siempre se han hecho algunos análisis interesados de las virtudes de este concepto y que se han propagado a los cuatro vientos sus ventajas, pero también creo que no se ha contado de la misma forma sus inconvenientes, aunque me consta que si se han analizado. No hay más que ver el estudio que ha publicado recientemente la Cloud Security Alliance (CSA) [PDF] donde tímidamente o superficialmente (como quieran ustedes llamarlo) analizan los principales problemas de seguridad con los que se encuentra el Cloud Computing llevado a sus extremos. Cloud Computing es por tanto una moda con grandes virtudes y con grandes defectos. Si no se desarrolla con sumo cuidado, el mismo concepto es, en sí mismo, una amenaza para la seguridad de las organizaciones. No conté las palabras que se usaron en la mesa redonda pero les aseguro que la palabra Seguridad salió muchas veces y la usaron todos los participantes en la mesa redonda, incluyendo algunos invitados del público. Evidentemente esto quiere decir algo, ¿no creen?

Seguro que seguiremos hablando del recién nacido “Cloud” porque va a dar mucho juego….

Comprobación privada de credenciales comprometidas mediante índices ofuscados y filtros de Bloom (4/4)

22 de junio de 2026 Por Leave a Comment

Artículo invitado de Iliya Garakh. Cuarta y última entrega de la serie iniciada en Comprobación privada de credenciales comprometidas (1/4).
Cierre de la serie. Hasta aquí hemos construido un esquema elegante y eficiente. Toca enseñar su talón de Aquiles: cómo un ataque de diccionario fuera de línea a partir de una única consulta puede llegar a anular la privacidad que el esquema pretende ofrecer, qué riesgos asume con el secreto del cliente, qué ocurre frente a un servidor malicioso o un adversario cuántico, y —sobre todo— cuándo es razonable desplegar esta construcción y cuándo no.

[Read more…]

Comprobación privada de credenciales comprometidas mediante índices ofuscados y filtros de Bloom (3/4)

16 de junio de 2026 Por Leave a Comment

Artículo invitado de Iliya Garakh. Tercera entrega de la serie iniciada en Comprobación privada de credenciales comprometidas (1/4).

Toca situar el esquema en el mapa. En esta entrega cuantificamos su rendimiento (almacenamiento, cómputo, ancho de banda, falsos positivos) y lo comparamos punto a punto con los protocolos existentes: el modelo k-anonymity de HIBP, las construcciones basadas en OPRF (Google Password Checkup, Apple iCloud Keychain), la private set intersection y la opción de descarga local del corpus. Es donde se ve dónde encaja la propuesta y dónde no.

En la entrega anterior construimos el protocolo de índices ofuscados con ruido determinista: el cliente envía la unión de sus k índices reales y d índices de ruido derivados de un secreto local, y el servidor responde con los bits del filtro en cada posición. Ahora la pregunta es práctica: ¿qué coste impone esto en producción y cómo se compara con lo que ya existe?

[Read more…]

Comprobación privada de credenciales comprometidas mediante índices ofuscados y filtros de Bloom (1/4)

1 de junio de 2026 Por Leave a Comment

Artículo invitado de Iliya Garakh, Process Improvement & Agile Methodologies.

Primera entrega de una serie de cuatro sobre cómo comprobar contraseñas filtradas sin revelarlas al servicio que responde. En esta entrega planteamos el problema, fijamos el modelo de amenaza y vemos por qué los enfoques basados solo en el hash —incluso con sal o con bcrypt— no resuelven la cuestión.

Una pregunta práctica a la que tarde o temprano se enfrenta todo gestor de contraseñas, plataforma de inicio de sesión único y sistema de autenticación empresarial: ¿cómo comprobar contraseñas filtradas sin revelarlas al operador del servicio de consulta? Servicios como Have I Been Pwned (HIBP) han popularizado el problema y propuesto su propia respuesta —el modelo k-anonymity— pero la pregunta de fondo sigue abierta: ¿cuánta información sobre la contraseña aprende inevitablemente quien responde la consulta?

[Read more…]

Bushcraft digital

26 de diciembre de 2025 Por

Imaginemos (sólo imaginemos, por favor) una situación extrema en la que la vida en la ciudad sea muy complicada. Desde una guerra hasta una falta de suministros básicos (y por básicos no hablamos de Internet) continuada en el tiempo. En este caso, algunos trataríamos de llegar a pueblos que conocemos y en los que los recursos naturales son mayores. Si consigo llegar a mi pueblo, tendré al menos agua potable, fuego, posibilidad de cazar (aunque no sepa hacerlo), recolectar frutos o encontrar setas comestibles. Posibilidades de sobrevivir. No parece gran cosa, pero desde luego mucho mejor de lo que sería la vida en esas circunstancias dentro de una gran ciudad. O eso creo, aunque espero no tener que comprobarlo.

Llevando esta situación al extremo, encontramos el bushcraft, entendido como la práctica de habilidades y conocimiento para sobrevivir y prosperar en el medio natural. Existen diferencias entre el bushcraft y la supervivencia pura; esta última suele estar acotada en el tiempo y viene impuesta, mientras que el objetivo del bushcraft es una estancia prolongada en la naturaleza, habitualmente de forma voluntaria. No obstante, cuando hablamos de una situación extrema imaginaria como a la que hacíamos referencia al principio de este post, planteada seguramente sería difícil diferenciar dónde empieza el bushcraft y acaba la supervivencia pura: es una situación impuesta, sí, pero seguramente a medio o largo plazo, en la que no únicamente buscaríamos sobrevivir unos días…

Discusiones filosóficas entre bushcraft y supervivencia aparte, más allá del idealismo de poder vivir en el medio natural y valerse por uno mismo, parece que últimamente aumenta el miedo a que una situación como la imaginada pueda darse en la realidad. Y factores como pandemias, apagones, catástrofes naturales, polarización política… ayudan a incrementar este miedo, con o sin razón. Aquí entran los preppers, los preparacionistas, personas que se preparan activamente para esta situación extrema almacenando herramientas y alimentos o diseñando planes de supervivencia.

Hay muchos manuales de supervivencia y bushcraft, y mucho material técnico: cuchillos, hachas, mochilas… pero en ninguno de estos libros, ni entre los materiales habituales de bushcraft o supervivencia, se habla de una supervivencia, o de un bushcraft, digital. Evidentemente, si la situación es de lucha por tu vida y de supervivencia en la montaña, a pocos nos preocupará un fichero PDF, un pendrive o una foto digital de nuestras últimas vacaciones. Pero ¿y si nuestra supervivencia no es en ese medio, sino en un medio urbano, tecnológico, avanzado… de otro país? ¿Cómo sería un preparacionista digital?

Volvamos a la situación imaginaria de partida, a ese extremo que hace que tengamos que cambiar radicalmente de vida. Pero en lugar de echarnos al monte, tenemos la suerte -o no- de meternos en un avión con lo puesto e irnos a una ciudad otro país de Europa. O de Norteamérica. O de LATAM. O de… vamos, a una ciudad de un país que no haya sido afectado por esa situación extrema y que siga su vida habitual en el primer mundo. Si fuera así, no serviría de nada disponer de un cuchillo de supervivencia o saber hacer fuego con un pedernal, pero sí que podría sernos útil información en formato digital. ¿Qué meteríamos en ese repositorio de supervivencia, o de bushcraft, digital, en ese “por si acaso”? Ojo, no digo que sea útil en la práctica, digo que podría serlo hipotéticamente… y que molestar, no molesta.

Dándole una vuelta a la situación, hay varias categorías de información digital potencialmente necesaria en esta situación. Antes de hablar de cada una de ellas, es necesario destacar que todo lo expuesto aplicaría no sólo a mí mismo, sino también a mi familia. Todos estos documentos los incluiría en el repositorio de supervivencia.

La primera categoría para incluir en ese repositorio es la más básica, la que me puede ayudar a decir quién soy, sirva luego o no. Así, lo primero que se me ocurre es digitalizar mi documentación de identidad. Mi pasaporte, en primer lugar, y mi DNI y permiso de conducir en segundo. Más allá de validez legal, que seguramente no la tiene, es lo único que tengo o puedo tener para demostrar que yo soy quien digo ser y no otra persona… ¿o no?

Una segunda categoría sería la que me permite algo más que identificarme, y es empezar a sobrevivir. Aquí identifico las cuentas bancarias y tarjetas asociadas, para poder disponer de dinero de alguna forma. También entrarían en esta categoría una copia del CV y los títulos académicos. Puede parecer una tontería, o ni siquiera estar convalidados, pero si tenemos que buscar trabajo, estos títulos pueden convertirse en la base de todo. ¿Quién o qué le dice a una persona de un país que soy ingeniero informático y no soy electricista, astronauta o taxidermista? Además, estos títulos tienen un número de registro único que, en algún momento, tras superar la situación extrema (si se supera) pueden sernos útiles para recuperar el título real. ¿O alguien se acuerda de memoria del número de registro o código de centro de su título? Ah, y por qué no, los ficheros de contraseñas: ese archivo cifrado, desde un KDBX a un PGP, con nuestras claves: correo, banca online, comercio… en fin, a los recursos que usamos en nuestro día a día.

Por último, la tercera categoría de documentación a digitalizar sería la que puede sernos útil a la vuelta, si la hay, a nuestras casas. Toda la anterior, por supuesto, pero también los títulos de propiedad, las escrituras de nuestra vivienda, el permiso de circulación o la ficha técnica de nuestro vehículo, entre otros. Sí, aquello que puede demostrar que algo de cierto valor nos pertenece. Si vuelvo a mi país, ¿quién demuestra que mi piso o mi coche son míos?

¿Dónde estaría el repositorio de supervivencia digital? Podría ser un pendrive o un disco USB con todos los archivos. O un repositorio en la nube, accesible desde cualquier lugar del mundo. O nuestro móvil, que a fin de cuentas es lo primero que cogeríamos si salimos corriendo de casa. O, mejor aún, en todos estos sitios. Cada uno tiene ventajas e inconvenientes. Un pendrive es privado, pero no deja de ser un dispositivo físico que tengo que intentar recuperar en un momento crítico en el que quizás mi cabeza está en otro sitio. Algo parecido sucede con el teléfono móvil, pero aquí tenemos unas ventajas sobre el pendrive: el móvil lo llevamos siempre con nosotros (ese pendrive o disco externo no) y además parte de nuestro repositorio de supervivencia está ya en el móvil, como son las tarjetas o alguna documentación identificativa. Por el contrario, si el móvil está descargado o bloqueado, no sirve de nada. Por último, la alternativa cloud es muy interesante desde el punto de vista de accesibilidad (¡ojo al 2FA si no tenemos móvil!), pero tiene el problema habitual de la nube: es el ordenador de otra persona, en el que nos puede dar reparo dejar documentación tan sensible… ¿no? Aquí, recordemos que esta información puede ir cifrada.

Antes de finalizar, unos comentarios: el primero, que esto surge de una situación extrema que ojalá no se produzca nunca, y que “irse” a otro país no es tan fácil. Sin ir más lejos, tenemos Estados Unidos y sus requisitos de acceso. El segundo, que se trata de meras ideas, no de una relación exhaustiva (seguro que con aportaciones de todos podemos mejorar el contenido de nuestro repositorio de supervivencia). Y el tercero, que no entramos en la validez legal de cada documento o su copia digitalizada. Sé que si llegas a Estados Unidos con un pasaporte en PDF o un título de ingeniero escaneado no te va a servir para que automáticamente todos te crean… pero daño no creo que haga. Simplemente se plantean ideas como base para poder empezar a hablar, aunque sea con un fichero PDF. Ah, y, por último: recuerda que este repositorio hay que mantenerlo actualizado, ya que algunos de los documentos caducan, o nuestras vidas cambian (nuevo vehículo, título adicional, etc.).

A modo de ficha resumen del repositorio de supervivencia:

  • Ubicación: móvil, nube o pendrive. O todos.
  • Contenido:
    • Prioridad 1: pasaporte, DNI, permiso de conducir.
    • Prioridad 2: CV, títulos académicos, cuentas bancarias, tarjetas, ficheros de contraseñas.
    • Prioridad 3: escrituras vivienda, títulos de propiedad, permiso de circulación, tarjeta vehículo…

Cripto-estafa postal (II)

16 de diciembre de 2025 Por

Continuo en esta segunda entrega analizando más en profundidad el Chat bot de Telegram y el código fuente de la web. Analizando la respuesta que da la web fraudulenta, se pudo extraer datos relevantes como el Chat_id:

Con la herramienta Curl me decido a extraer más información del bot  de telegram:
Con la orden GetMe a la api de telegram extraemos información básica sobre el Bot:

[Read more…]

Cripto-estafa postal (I)

10 de diciembre de 2025 Por

El mundo de las criptomonedas y la posibilidad de diversificar los ahorros, han hecho que a día de hoy muchas personas quieran asumir un riesgo y diversificar su cartera de ahorros incluyendo cripto-activos. En mi caso decidí hacerlo de forma cautelosa y a ser posible de la forma más segura posible usando una billetera fría o “cold wallet”, concretamente el modelo “Ledger Nano S”.

La diferencia fundamental de usar una billetera fría es que tú mismo eres el que custodia la clave privada y la frase semilla que te permite recuperar la billetera en caso de pérdida, a diferencia del uso de un Exchange online.

El 14 de julio de 2020 Ledger fue alertado por un investigador propio de su programa de bug bounty de una posible brecha de seguridad. La brecha consistía en que un tercero no autorizado

 podría acceder a una parte de la base de datos de comercio electrónico y marketing mediante una API key que había sido asignada a un tercero.  Más tarde se comprobó que el 25 de junio de 2020 fue la fecha en la que el acceso malicioso había comenzado aprovechando dicha brecha.

Ledger informó que aproximadamente 1000000 de direcciones de correo electrónico estaban comprometidas, de las cuales 272.000 clientes estaban afectados por la exposición de datos personales como nombre/apellidos, dirección y teléfono.

A partir de esa fuga de datos, empecé a recibir mails, llamadas y sms fraudulentos, con el fin de conseguir las palabras que forman la frase semilla. La mayoría de estos intentos  fueron fáciles de detectar como estafa, aquí muestro algunos ejemplos:

[Read more…]

Veeam Backup: De seguro de la organización a llave maestra del atacante

5 de mayo de 2025 Por

Muchos de vosotros seguro que conoceréis Veeam Backup, la solución de protección de datos que permite realizar copias de seguridad y recuperaciones en entornos virtuales, físicos, NAS y nativos de la nube. Esto se debe a que su facilidad de uso y eficiencia lo han convertido en un pilar fundamental en la estrategia de backup de muchas organizaciones.

En un contexto donde los ataques de ransomware están a la orden del día, Veeam Backup se ha consolidado como una herramienta esencial para la continuidad del negocio y la resiliencia ante la nueva oleada de amenazas que reciben las organizaciones de hoy en día.

Sin embargo, ¿qué pasaría si esta solución de protección se convirtiera en la puerta de entrada para un actor malicioso?

Una de las grandes ventajas de Veeam Backup es su capacidad para integrarse fácilmente con otras soluciones clave en entornos IT. Es común verlo conectado con vSphere, la plataforma de virtualización de VMware, o con sistemas NAS, utilizados para el almacenamiento de datos en red.

Además de ello, su compatibilidad con múltiples soluciones cloud ampliamente utilizadas, como es el caso de Azure, lo convierte en una pieza fundamental para la gestión eficiente y segura de copias de seguridad en la nube.

En el mundo IT, la automatización de tareas, especialmente cuando involucra la integración entre distintos softwares, conlleva beneficios significativos. Sin embargo, también implica ciertas condiciones, en su mayoría relacionadas con el proceso de autenticación. Es fundamental evaluar estos aspectos, ya que pueden influir en la seguridad, el control de acceso y la privacidad de los datos, por lo que es necesario sopesar sus ventajas y posibles riesgos antes de implementarlos.

[Read more…]

Baklava CTF Writeup – Incident Report Style (I)

7 de abril de 2025 Por

Contenido

  1. ¡WARNING! ¡LÉEME PRIMERO!
  2. Resumen ejecutivo.
  3. Antecedentes.
  4. Gestión del incidente
    • 4.1. DC02 – 192.168.20.46
    • 4.2. WS02 – 192.168.20.42
    • 4.3. WS01 – 192.168.20.41
    • 4.4. SRV01
  5. Conclusiones finales.
  6. Línea temporal del ataque.
  7. Impacto.
  8. Atribución.
  9. Lecciones aprendidas.
  10. Anexo A: IOC.
  11. FAQ (del meta, no del incidente).

Informe de Incidente BAKLAVA Parte 1

1. ¡WARNING! ¡LÉEME PRIMERO!

Este documento que estás leyendo es un informe “real” de un incidente ficticio, basado en el CTF DFIR que los compañeros Andrés Yedra y Arturo Martínez (unos fieras) montaron hace poco y que puedes encontrar aquí: https://ctf.communia.cc (y que por supuesto puedes jugar, aunque si piensas hacerlo deja de seguir leyendo porque los spoilers son más que abundantes y se pierde toda la gracia…)

Me han pedido en muchas ocasiones un “documento de ejemplo” de gestión de un incidente, tanto desde la parte de cómo investigarlo como de la parte de cómo redactarlo. En S2 Grupo tenemos como … muchos de esos documentos, pero aunque tengas todo el cuidado del mundo anonimizándolos siempre se corre un riesgo, así que hemos decidido partir de un incidente sintético. Disfruta y aprende, que el gusanillo del DFIR tiene lo suyo ;)

[Nota: todo lo que veais entre corchetes como notas… son eso, notas que no aparecerían en un documento formal, pero que creo que son de utilidad para aclarar alguna duda y sacarle el máximo provecho al análisis].

2. Resumen ejecutivo

El 22 de marzo de 2024 a las 15:30h Megacorp entra en contacto con nosotros porque ha sufrido un incidente de ransomware. Se despliega un equipo de respuesta ante incidentes, que obtiene evidencias de varios de los servidores y puestos de usuario de la Organización

Los análisis llevados a cabo permiten determinar que los atacantes enviaron un correo malicioso a uno de los usuarios de la Organización. Dicho correo tenía un enlace a un documento malicioso, que el usuario abrió infectando su puesto de usuario.

Los atacantes fueron capaces de obtener privilegios gracias a un fallo en los permisos de un directorio del equipo, y gracias a esos privilegios pudieron infectar otro equipo de usuario.

En dicho equipo realizan un ataque contra el dominio Windows que les permite obtener otro usuario privilegiado, con el que inician sesión en el servidor de datos, deshabilitan el antivirus y obtienen las credenciales existentes en el mismo.  De la misma forma, con otro usuario privilegiado logran robar una copia de todos los datos de las cuentas de usuario de la Organización (incluida una copia cifrada de las contraseñas).

Con dichas credenciales inician sesión en el controlador de dominio, y roban una base de datos de contraseñas empleada por IT (fichero de KeePass). A continuación, descargan el ransomware y lo detonan, cifrando ficheros del servidor.

Se tiene una confianza alta de que los atacantes no han realizado más actividades maliciosas en otros equipos de la Organización. Sin embargo, se recomienda un cambio generalizado de todas las contraseñas (con énfasis en aquellas cuentas con privilegios), así como restaurar desde las copias de seguridad de los servidores a una fecha anterior a las 13:00h del 22 de marzo de 2024.

[Read more…]