Cuando una organización migra o nace en AWS, suele aparecer una suposición peligrosa: que la seguridad es principalmente una cuestión de habilitar servicios suficientes en la consola.

“Si activamos WAF, GuardDuty, Security Hub y algunas reglas administradas, deberíamos estar cubiertos”.

Esta idea es comprensible… y profundamente equivocada.

AWS ofrece uno de los conjuntos de capacidades de seguridad más completos de la industria. Sin embargo, ninguna herramienta —por avanzada que sea— puede compensar una arquitectura mal diseñada. En la práctica, la postura de seguridad de un entorno cloud está determinada mucho más por sus decisiones arquitectónicas que por la cantidad de servicios activados.

Este patrón se repite tanto en startups como en organizaciones con plataformas complejas y cientos de aplicaciones en producción.

El problema estructural: la seguridad llega tarde

En muchos proyectos, la historia es casi siempre la misma:

• Se diseña y se construye la aplicación.
• Se despliega a producción
• El negocio crece, la plataforma se vuelve crítica
• Aparece una auditoría, un incidente o un requisito de cumplimiento.
• Recién entonces se intenta “endurecer” la plataforma

El resultado suele ser una superposición de controles reactivos sobre una base que nunca fue pensada con la seguridad como requisito fundamental. Se corrigen los síntomas visibles, pero no se elimina la causa raíz.

AWS no te hace seguro: te da el material para construir seguridad

AWS es, por diseño, extraordinariamente flexible. Esa misma flexibilidad permite construir tanto arquitecturas sólidas y bien aisladas como entornos frágiles, difíciles de entender y aún más difíciles de defender.

Con exactamente los mismos servicios es posible crear:

• Plataformas con segmentación clara, límites de confianza bien definidos y mínimo privilegio real
• O entornos planos, con dependencias implícitas, permisos excesivos y superficies de ataque innecesarias.

La diferencia no está en qué servicios se usan, sino en cómo se ensamblan y bajo qué principios.

El espejismo de la “seguridad activada”

Es común encontrar entornos que cuentan con:

• AWS WAF y conjuntos de reglas administradas
• Servicios de detección como GuardDuty y Security Hub
• Centralización de registros en CloudWatch o S3

Y aún así presentan críticas de debilidades, por ejemplo:

• API sin controles adecuados de autorización a nivel de objeto o propiedad (BOLA / BOPLA)
• Roles IAM con permisos ampliamente sobredimensionados
• Segmentación de red deficiente o inexistente
• Recursos internos expuestos sin una necesidad real
• Ausencia de control efectivo del tráfico de salida
• Grandes volúmenes de troncos que nadie revisa de forma sistemática

El resultado es una percepción de control, no una postura de seguridad robusta.

Donde realmente se decide la seguridad: en el diseño

La seguridad de una plataforma en AWS se define mucho antes del primer despliegue, al responder preguntas como:

• ¿Qué ocurre si este componente se ve comprometido?
• ¿Hasta dónde puede propagarse ese compromiso?
• ¿Qué relaciones de confianza existen entre servicios y son realmente necesarios?
• ¿Dónde se valida la autorización: en el perímetro, en la API, en la capa de negocio?
• ¿Cuál es el impacto máximo aceptable de un fallo o una intrusión?

Si estas preguntas no forman parte del proceso de diseño, los controles añadidos después siempre serán paliativos.

Seguridad como propiedad intrínseca de la arquitectura.

Una arquitectura bien diseñada:

• Contiene los incidentes en lugar de amplificarlos.
• Reducir la superficie de ataque de manera estructural.
• Aplicar el principio de mínimo privilegio de forma coherente
• Segmentas funciones, redes y responsabilidades
• Asume que los fallos ocurrirán… y los aísla por diseño

En este contexto, los servicios de seguridad de AWS dejan de ser un intento de compensación y pasan a ser aceleradores de una buena arquitectura.

El cambio de mentalidad que separa equipos maduros de equipos reactivos
❌ “¿Qué servicio de seguridad nos falta activar?”
✅ “¿Qué sucede si este componente falla o está comprometido?”

Esta diferencia de enfoque separa a los equipos que simplemente operan infraestructura de los que diseñan plataformas resilientes y seguras para la construcción.

Conclusión

AWS no es inseguro.
Pero ninguna plataforma es más segura que su arquitectura.

En la nube, la seguridad:

• No se compra
• No se activa
• Se diseña

Y cuanto antes forme parte del diseño, menor será el costo —técnico, operativo y reputacional— de operar la plataforma en el futuro.

0 1

Hoy en día en el entorno laboral es casi indispensable contar con un perfil profesional en línea. Tener un perfil profesional en una red social como LinkedIn es clave en el campo laboral por que hace las veces de tarjeta de presentación digital y abre oportunidades que antes solo eran posibles con interacciones presenciales.

Dentro de las ventajas mas sobresalientes, están:

• Hace posible ser encontrado por reclutadores y empresas caza talento.
• Realza tu marca personal, por medio de tu experiencia, logros y habilidades.
• Permite establecer conexiones profesionales con colegas, lideres de la industria y posibles empleadores.
• Brinda acceso a comunidades y grupos especializados afines.
• Un perfil actualizado y correctamente diligenciado, transmite credibilidad y profesionalismo.
• Permite tener acceso a vacantes exclusivas que muchas veces solo se publican en redes profesionales.

Dicho de otro modo, tu perfil profesional es una exposición de tu trayectoria y potencial.

Teniendo en cuenta todas las bondades que ofrece contar con un perfil en una red social profesional, no tenerlo no es una buena opción. Pero ¿cómo manejarlo correctamente y no ser blanco de estafas?

En cualquier oficio u ocupación, se corren riesgos de caer en estafas, ser víctima de phishing, o usurpación de identidad. Sin embargo, por lo complejo y difícil de detectar, hoy hablaremos de los riesgos en las ofertas de empleo de programación. 

Para dar un alcance a nuestro post, mencionaremos dos casos. El primero que mencionaré, es el que relata en sus redes sociales la influencer Arelis Reyes, de Kevin Miani.  Ella relata lo siguiente:

“Me quisieron hackear en una entrevista de trabajo. Me llegó un mensajito por LinkedIn, foto profesional, experiencia real, todo limpio. “Hola, estamos buscando un Full Stack Web 3 Developer. Queremos evaluar tu capacidad para revisar este repositorio en GitHub. “

Yo ingenua, pero emocionada, pensé, ok, esto es normal. En muchas entrevistas técnicas te mandan un repositorio para que lo ejecutes, revises el código y ellos vean tu proceso. Es una dinámica común, nada extraño, pero ahí es donde las cosas se ponen raras. Abro el repo, todo normal, pero dentro del folder, en Node_Modules, había un paquete modificado, apenas perceptible. Para los que no sepan, Nodul Modules es la carpeta donde viven todas las dependencias que tu proyecto necesita. Y también nadie las revisa una por una porque confiamos en la comunidad, en los mantenedores, en los paquetes populares. Por eso se vuelve la caja negra perfecta para esconder algo, y ahí había un paquete que parecía completamente común.

Nombre normal, archivo normal, pero dentro tenía un código malicioso. Y luego me di cuenta de que el atacante había refinado el malware. Lo que hicieron fue cambiar el nombre del archivo malicioso de react-svg-config a react-svg-provider.

Mismo contenido, diferente máscara. ¿Para qué? Para evitar auditorías automáticas. Las auditorías automáticas son revisiones que hace NPM cuando ejecutas cosas como NPM Audit o cuando instalan las dependencias.

NPM revisa si hay algún paquete sospechoso, si hay alguna vulnerabilidad conocida o si su estructura no coincide con la versión pública. Imagínate que es como un escáner del aeropuerto revisando tu mochila en un segundo. Al cambiarle el nombre, el archivo parecía nuevo, no coincidía con nada reportado.

Y pasó las revisiones sin levantar alertas. Después, en otra actualización dentro del repo, el atacante metió la parte final del ataque en el archivo vite.config.js. Este archivo se ejecutaba cada vez que arrancabas el proyecto, así que era el lugar perfecto para insertar un payload sin que nadie lo notara. Y justo ahí estaba el código diseñado para activarse cuando yo corriera NPM Install.

Este script podía robar variables de entorno, credenciales, tokens, llaves privadas, información del sistema, prácticamente cualquier cosa que yo tuviera en mi entorno. Y lo más preocupante, el código estaba hecho para autodestruirse después de ejecutarse. No dejaba ningún rastro.

Si no lo detectabas en ese instante, jamás te ibas a enterar. Esta es la historia de Kevin Miani, quien detalló todo en LinkedIn. Y lo que dice es claro, ten mucho cuidado con lo que ejecutas.

La revisión inicial es crucial. Y aunque parezca solo una prueba técnica, no puedes ejecutar código desconocido sin aislarle. Y mucho menos confiar ciegamente en repositorios enviados por perfiles que no conoces.

Esto no es para asustar a nadie, es para que sepas que este tipo de ataques existen y cualquiera podría caer en ellos si no tomamos las precauciones mínimas.”[1]

El segundo caso, lo cuenta el creador de contenido argentino, Dager.32. Relata lo siguiente:

“Me contactó un italiano y ofrecía una locura de plata. Obviamente le dije que sí, hoy me mandó a ejecutar un proyecto Mern y creo que me cabió. El CPU se fue al 100%, estoy desinstalando todo, tengan cuidado.

La otra vez les mostré acá en stream un intento de scam que me cayó por también una oferta laboral. Generalmente son las que vienen relacionadas a cripto, es increíble. Y el proyecto, me dijeron, “este es el proyecto, podés verlo”.

Me pasaron el código, viste, el repo, y tenía un código sumamente ofuscado, parecía código legit, pero de repente veías los commits y eran medio raros, y de repente ibas al código y había un código muy ofuscado, como convertido en un montón de strings dando vueltas, loops raros, que vos decías que no sé ni para qué están haciendo esto, y como que te trataba de confundir básicamente tanto con complejidad innecesaria como con literalmente código ofuscado, nombres de funciones unificadas y toda la boludez. Y era, obviamente no me descargué el repo ni nada. Tengan cuidado con eso, no se descarguen ningún repo si van a hacer algo así, hasta que no vean que les están garpando el sueldo, no toquen nada, no se descarguen nada al pedo, y en todo caso si van a poner algo pónganlo en una máquina virtual con cuidado, porque es verdad que hay un montón de scams dando vueltas.”[2]

Como podemos observar en ambos casos, las ofertas de empleo fueron utilizadas como señuelos para hacer caer en la estafa a quienes nos están narrando su experiencia. Vemos que cuando son ofertas de programación, esconden y filtran “pequeñas” variantes en los códigos fuente, intentando pasar desapercibidos. Solo quienes observan detenidamente, son alertados a tiempo antes de descargar o instalar algo en sus equipos.

Este post no tiene el propósito de profundizar en temas técnicos de programación, el objetivo de este, es mostrar este tipo de estafa y alertar a todos nuestros lectores de que es una modalidad cada vez mas utilizada.

Por esto, hemos hecho un resumen de las recomendaciones que debemos tener en cuenta para evitar ser estafados a través del reclutamiento de un perfil profesional por medio de una red social (por ejemplo LinkedIn).

Recomendaciones:

• La revisión inicial es crucial. Antes de ejecutar o instalar cualquier aplicación o complemento, revise de manera detallada el código.

• NO confiar ciegamente en repositorios enviados por perfiles que no conoce. Sea precavido.

• Evite al máximo descargar repositorios hasta que no sea seguro. Por ejemplo, que ya lo hayan contratado y sea algo para su periodo de prueba, o exista un contrato de por medio.

• NO crea en ofertas millonarias y menos cuando la primera tarea es descargar o ejecutar algún código. Desconfié.

• Tenga mucho cuidado con lo que ejecute. Si ya ejecutó, revise que su equipo no adopte un comportamiento extraño, que no haya hecho instalaciones paralelas o adicionales y que los recursos del sistema no presenten anomalías.

• Si definitivamente es necesario que descargue o realice un ejercicio en el cual debe interactuar con dicho repositorio, utilice una máquina virtual con todas las precauciones.

Por: Ing. Arianis Livingston Martínez

---

[1] https://www.instagram.com/reel/DRYOV-ijjDh/

[2] https://www.instagram.com/reel/DRckg5ZjcGi/?igsh=NGs5cThha2tpd3V2

0 2

En la actualidad es muy común escuchar sobre la importancia de las copias de seguridad y los respaldos de nuestra información en dispositivos, bien sean laptop, equipos de mesa, celulares, tablets, etc. Prácticamente todo dispositivo electrónico, es susceptible a la elaboración de copias de seguridad.

En un mundo donde la ciberdelincuencia va en aumento y a pasos agigantados, todo mecanismo de prevención y mitigación, es bienvenido. La pregunta es, ¿cómo respaldamos aquellos servicios que utilizamos de manera gratuita de proveedores de correo electrónico (Gmail, Yahoo, Outlook, entre otros), y que toda nuestra información está en sus servidores?

Alguna vez has pensado, que cuando hackean un correo electrónico, o accidentalmente se queda tu sesión abierta en un equipo de uso común, quien tenga acceso a él, sea ciberdelincuente o un usuario desconocido, tiene todo el poder sobre tu correo, incluso, eliminar todos los mensajes de tus bandejas. ¿Suena algo serio y preocupante verdad?, pues así es.

Pero no te preocupes, en este post, te enseñaremos a realizar una copia de seguridad de Google para los que utilizan Gmail. Cada proveedor tiene sus formas, pero para efectos de esta entrada, utilizaremos Gmail, que es el correo más utilizado en el mundo.

1. Lo primero que debe hacer es tener la sesión de correo iniciada. Luego en una pestaña diferente ingrese a https://takeout.google.com/
2. Google Takeout te permite seleccionar exactamente qué datos quieres exportar. Para excluir Drive, en principio, haga clic en “deseleccionar todo”, marque solo “correo” y verifique que “drive” este desmarcado.

3. Seguir los siguientes pasos para crear y descargar el archivo.

En la siguiente pantalla, seleccionamos el destino del enlace de descarga. En este caso escogimos el correo electrónico. En frecuencia, podemos programar dichas copias de forma periódica. También nos permite escoger el tipo y tamaño de archivo. Se recomienda escoger .Zip y 2 GB respectivamente como lo coloca el sistema por defecto.

4. Finalmente inicia la exportación y nos muestra el estado de la descarga, informando que es un proceso que tarda mucho tiempo en completarse y que al finalizar, recibiremos un correo de notificación.

5. Al correo objeto de la copia de seguridad nos llega una notificación de Google (por seguridad), informando sobre la solicitud. No hay que hacer nada.

6. Cuando finalice la copia, nos llega un correo informando y con el link de descarga, al cual hacemos clic.

7. Luego nos envía a descargar la información. Como se observa, lo divide en partes de acuerdo al peso de la copia.

En las descargas podemos apreciar el avance de la misma.

8. Esto generará un archivo .mbox con tus correos, que puedes abrir con programas como Thunderbird.

Con estos sencillos pasos, puedes implementar tus propias medidas de seguridad ante un acceso no autorizado a tu bandeja.

Se recomienda que este proceso se haga principalmente con el correo, dejando por fuera los demás componentes de Google, ya que entre más ítems seleccionemos, hace el proceso mucho más demorado y el archivo final mucho más pesado. La idea es priorizar.

Por último, pero no menos importante, la idea es que esta copia quede almacenada en un dispositivo extraíble, en otro equipo o si es posible en la nube. Si tu equipo se daña, pues cuentas con ese respaldo.  

Por: Ing. Arianis Livingston Martínez

0 3