Novedades de OWASP Top 10 2021 (I)

OWASP, Open Web Application Security Project o Proyecto Abierto de Seguridad en Aplicaciones Web, es un proyecto que tiene como finalidad mejorar la seguridad en las aplicaciones web.

También es una comunidad abierta, dedicada a permitir que las organizaciones desarrollen, adquieran y mantengan aplicaciones en las que se pueda confiar.

El proyecto OWASP está respaldado por la Fundación OWASP, la cual nace el 1 de diciembre de 2001 y está registrada como organización sin ánimo de lucro en Estados Unidos desde el 21 de Abril de 2004.

Entre sus actividades destacan:

  • Proyectos de software de código abierto liderados por la comunidad
  • Más de 200 capítulos locales en todo el mundo
  • Decenas de miles de miembros
  • Conferencias educativas y de formación líderes en la industria

En su página nos indican cuales son los valores clave que definen al proyecto, según sus palabras, tienen un carácter:

  • Abierto: Todo en OWASP es radicalmente transparente desde nuestras finanzas hasta nuestro código
  • Innovador: Fomentamos y apoyamos la innovación y los experimentos para encontrar soluciones a los desafíos de seguridad del software.
  • Global: Se anima a cualquier persona en todo el mundo a participar en la comunidad OWASP.
  • Integridad: Nuestra comunidad es respetuosa, solidaria, veraz y neutral con respecto a los proveedores.
[Read more…]

Desinformación y ciberseguridad: De los “últimos de Filipinas” a los últimos en verificar una noticia

Dado que los españoles somos una raza muy aficionada a ignorar nuestra historia y, por tanto, nos privamos de la capacidad de interpretarla de forma objetiva y desprendida de cualquier sesgo interesado, puede que sea oportuno comenzar recordando el episodio histórico de “los últimos de Filipinas”.

En su libro “El sitio de Baler. Notas y recuerdos” (libro traducido al inglés y cuya lectura se recomienda en el Ejército de los Estados Unidos de Norteamérica) el Teniente Saturnino Martín Cerezo narra la gesta de un grupo de cincuenta soldados españoles sitiados durante 11 meses, entre el 30 de junio de 1898 y el 2 de junio de 1899, en la iglesia de San Luis de Tolosa de la localidad de Baler, en la isla filipina de Luzón; éste es uno de sus pasajes:

“El mismo día 30 (de septiembre) recibimos una carta del gobernador civil de Nueva Écija, señor Dupuy de Lome. Nos participaba en ella la pérdida de Filipinas, y el mismo comandante político-militar, que dijo conocerle, no pudo menos de manifestar que si en circunstancias normales hubiera recibido aquel mensaje pidiéndole dinero, lo hubiese dado sin titubear un sólo instante, porque la letra, que también aseguró conocer, parecía la verdadera. Siguieron a esta carta las actas de capitulación del comandante D. Juan Génova Iturbe; del capitán D. Federico Ramiro de Toledo, y de otros que no recuerdo. Luego fueron sucesivamente participándonos que se había rendido el comandante Caballos, destacado en Dagupán, y entregado 750 fusiles; que el general Augustí había capitulado en Manila porque su señora estaba prisionera de los tagalos, y otra porción de noticias por el estilo. Cerró la serie aquella, otra carta del cura de Palanán, Fr. Mariano Gil Atianza, resumiendo y confirmándolo todo, diciéndonos que se había perdido el Archipiélago; que ya no tenía razón de ser nuestra defensa y que depusiéramos inmediatamente las armas, sin temor ni recelo, porque nos tratarían con todo linaje de atenciones.

Preciso es confesar que tanto y tan diverso testimonio era más que sobrado para convencer de la realidad a cualesquiera; mas conocíamos el empeño, la cuestión de amor propio que tenían los enemigos en rendirnos, y esta idea nos mantenía en la creencia de que todo aquello era supuesto y falsificado y convenido. Por esto cuando nos participaron que tenían con ellos a varios de los que habían capitulado, les contestamos que nos los llevasen para verlos y por esto no dimos crédito ni a la evidencia de la carta del gobernador de Nueva Écija, ni a las actas ni a nada. Por otra parte, no cabía en la cabeza la ruina tan grande que nos decían; no podíamos concebir que se pudiera perder con tanta facilidad aquel dominio; no nos era posible ni aún admitir la probabilidad de una caída tan rápida y tan estruendosa como aquella”.

Supervivientes del destacamento de Baler fotografiados el 2 de septiembre de 1899, a su llegada a España (Museo del Ejército)
[Read more…]

Log4Shell: Apache Log4j 2 CVE-2021-44228

Si no has estado viviendo debajo de una piedra las últimas horas, sabrás que el viernes pasado comenzó a hacerse viral una vulnerabilidad crítica del paquete Log4j 2, una librería de log de Java utilizada masivamente.

Esta vulnerabilidad, bautizada como Log4Shell y descubierta por Chen Zhaojun (ingeniero de software de Alibaba), ha sido asignada el CVE CVE-2021-4428, con un CVSS de 10.0.

Aunque a estas alturas hay toneladas de información pública al respecto, vamos a dar algunas pinceladas sobre ella.

Los actores

Log4j 2: el plugin Lookup

Como hemos comentado, Log4j 2 es una librería de log para aplicaciones Java utilizada por los desarrolladores para loguear información de la aplicación. Utilizarla es tan sencillo como incluir algo como log.debug(“Mensaje de prueba”); en el código, lo que generará que se registre una entrada en el log. A menudo, la información que se registra está relacionada con la propia aplicación y su contexto de ejecución.

Una de las capacidades de la librería, denominada Lookups, es la posibilidad de utilizar variables al escribir en el log, que serán sustituidas por el valor correspondiente, con una sintaxis específica: ${variable}. Por ejemplo, si utilizamos ${java:runtime}, cuando la aplicación grabe en el log, registrará la version del Java runtime.

[Read more…]

Purple Team: ¿pero esto qué es? (III). Vectr.io

Como ya podéis suponer por anteriores spoilers, en esta tercera parte de la serie (ver primera parte y segunda parte), tras haber dejado claro el papel que juega la Inteligencia de Amenazas en la metodología Purple Team, entraremos un poco más en detalle sobre las fases de preparación, ejecución y lecciones aprendidas en un ejercicio.

Disclaimer: Como ya comenté en el primer episodio, no pretendo sentar cátedra con este artículo sino más bien, aportar mi punto de vista y aportar una visión de conjunto sobre el un tema del que no se encuentra gran cantidad de documentación (sobre todo en español), y la que se encuentra, está dispersada en múltiples fuentes.

Tras haber desarrollado un plan de ejecución tomando como referencia el mapeado de las amenazas sobre la MITRE ATT&CK MATRIX, es hora de llevar a la práctica todos los casos de uso. Para ello usaremos Vectr.io, una plataforma web de código abierto desarrollada por Security Risk Advisors.

Esta herramienta se encarga de centralizar todas las tareas de coordinación de los equipos Red y Blue. Pero lejos de ser una herramienta solo para coordinar los ejercicios, también está preparada para ser utilizada como una suerte de bitácora de todas las operaciones ejecutadas en diversos ejercicios a lo largo del tiempo, de forma que se pueda realizar un seguimiento de la evolución de la postura de seguridad de la organización a lo largo del tiempo.

Con una descripción abstracta como la anterior, puede ser difícil imaginar cómo se consigue todo esto. Por ello, el objetivo de este post es optar por un enfoque más práctico.

En aras de la brevedad, no vamos a entrar en detalle de todas las funcionalidades de esta herramienta sino que mostraremos las posibilidades que ofrece y como estas nos pueden ayudar con nuestro objetivo. Será de ahí en adelante tarea de cada uno explorar las funciones más avanzadas y evaluar si le son útiles para su caso particular.

[Read more…]

Evadiendo el antivirus mediante Early Bird y Syscalls

Uno de los problemas que se intentan evitar durante el desarrollo de un proyecto Red Team es generar alertas que puedan hacer sospechar al Blue Team que un activo ha sido comprometido. En este tipo de proyectos la discreción es fundamental.

Es probable que, si se levantan suficientes sospechas, el Blue Team actúe y se pierda un punto de entrada ya conseguido. Puede que sea incluso necesario reconstruir toda la infraestructura de ataque (probablemente el Blue Team obtendrá IOCs y marcará como maliciosos las IPs, dominios, artefactos, etc. que se estén utilizando). Incluso tras reconstruir la infraestructura de ataque, puede que resulte muy difícil encontrar otro punto de entrada.

Por este motivo, uno de los aspectos que es necesario tener en cuenta en el desarrollo de los artefactos que se preparen para el ejercicio es la evasión del antivirus. Las técnicas de detección utilizadas por los servicios de antivirus instalados en los equipos de usuario van mejorando mucho con el tiempo, principalmente con la incorporación del análisis en la nube.

No obstante, las técnicas utilizadas por los profesionales que trabajan en la parte ofensiva y, cómo no, también por los atacantes reales, también han mejorado notablemente, obligando a mejorar continuamente las protecciones y formas de detección.

En este artículo se comentan un par de técnicas que se explican en profundidad en los cursos RED TEAM Operator: Malware Development Essentials y Intermediate Course del Sektor7 Institute, cursos muy recomendables ya que tienen un temario variado y son muy prácticos.

El código utilizado en los ejemplos de este artículo está basado en el que se presenta en estos dos cursos.

Early Bird es una técnica de inyección de código que hace uso del mecanismo implementado en Windows para las llamadas asíncronas a procedimientos, también conocido como APC o Asynchronous Procedure Calls. Esta funcionalidad permite la ejecución asíncrona de código en el contexto de un determinado proceso y resulta interesante porque puede ser utilizada para la ejecución de código malicioso antes de que llegue a ejecutarse el punto de entrada del hilo principal del proceso original.

[Read more…]

Steal ’em all! Token impersonation

Durante un proceso de intrusión, el robo de Tokens y la impersonación de usuarios nos puede ser de gran ayuda, ahorrándonos mucho tiempo y favoreciendo el permanecer lo más sigilosos posibles utilizando tan solo las capacidades y herramientas que el propio sistema operativo Microsoft Windows nos ofrece.

Antes de comenzar y a modo de recordatorio, un Token dentro del sistema operativo Microsoft Windows es un elemento de seguridad que dota de identificación a procesos e hilos cuando estos quieren realizar acciones sobre objetos securizables del sistema (ficheros, registros, servicios…).

En las siguientes líneas vamos a ver cómo es posible robar el Token de casi cualquier proceso en ejecución en el equipo utilizando tan solo dos técnicas diferentes, siempre y cuando tengamos los privilegios y permisos necesarios para poder llevarlo a cabo.

Como todo en este mundo parte de un trabajo previo, el reto y la inspiración de la investigación partió de este magnífico post de Justin Bui (@slyd0g) de SpecterOps, del que rebatiremos algunas de sus conclusiones, así como el de Chintan Shah de MacAfee  “Technical Analysis of Access TokenTheft and Manipulation”, el cual referencia al primero.

Pero ¿por qué nos puede interesar robar un token de un proceso o hilo concreto del sistema?

La respuesta rápida y corta es para elevar privilegios y realizar acciones que con el token actual no podemos llevar a cabo o para movernos lateralmente hacia otro equipo de la red. Un ejemplo de lo primero lo tenéis en el anterior post “TrustedInstaller, parando Windows Defender”, aunque ahora veremos alguno más.

[Read more…]

Mythic

NOTA: El contenido de este artículo es educativo e informativo. El objetivo es aprender cómo funciona la aplicación Mythic y cómo identificar sus capacidades. El autor no se hace responsable de una mala utilización de la información aquí expuesta ni las consecuencias legales que se pudieran derivar de ella.

¿Qué es Mythic?

Mythic es una plataforma de código abierto que busca proporcionar un entorno para las fases de post explotación de C2 (Comando y control).

Entre sus características destaca que es altamente personalizable, rápidamente desplegable, modular y pensado para el trabajo de múltiples operadores al mismo tiempo.

Mirando con lupa

Mythic se compone de diferentes servicios que conforman el conjunto de funcionalidades que es la plataforma.

[Read more…]

Purple Team: ¿pero esto qué es? (II). Threat Intelligence

Tras haber hecho una introducción y exposición somera de la metodología Purple Team y enumerado las fases que la componen en la primera parte de esta serie, en esta segunda voy a entrar en más detalles sobre cómo se integra la inteligencia de amenazas (Cyber Threat Intelligence o CTI) en todo el proceso de emulación adversarial, y por ende, en los ejercicios o programas Purple Team.

Lo primero: entender la organización objetivo

Tanto si se está realizando CTI como consultor externo como si se forma parte de la organización, es importante contar con la mayor información posible sobre la organización.

Para ello, el equipo de CTI debe llevar a cabo un intenso y extenso ejercicio de obtención de información, de la misma forma que la obtendría un agente de amenazas enemigo. Además de esto, la información debe enriquecerse con la obtenida mediante entrevistas y consultas al personal de la organización.

El objetivo es identificar la superficie de ataque de las personas, procesos, tecnologías y sistemas que forman parte de la huella digital de la organización para crear una visión preliminar de la exposición desde la perspectiva del atacante, y contribuir así al descubrimiento de posibles escenarios de ataque que se incluirán en el informe de CTI.

Identificar el adversario a emular

[Read more…]

Deconstruyendo la gestión de riesgos (I): el riesgo inherente

Los seres vivos somos expertos en gestionar riesgos. Es algo que hemos hecho a lo largo de millones de años. Se llama, entre otras cosas, instinto de supervivencia. No estaríamos aquí si se nos diera mal.

Los evitamos, los mitigamos, los externalizamos, los asumimos.

Por ejemplo, ¿va a llover hoy? Si llueve, ¿cuánto va a llover? ¿Me llevo el paraguas? ¿Me quedo en casa? ¿Me encontraré con un atasco de camino al trabajo? ¿Llegaré tarde a la reunión? ¿Llamo para avisar? ¿Intento posponer la reunión? ¿Pincharé una rueda de camino a casa? ¿Cuándo fue la última vez que revisé la rueda de repuesto? ¿He pagado la prima del seguro? ¿Cuál es la cobertura de asistencia en carretera?

Todos esos procesos cotidianos de identificación y valoración de riesgos los realizamos de manera inconsciente a diario, y aplicamos medidas de gestión del riesgo sin apenas darnos cuenta. Cogemos un paraguas, llamamos a la oficina para avisar del retraso, asistimos a la reunión por teléfono, salimos antes de casa o decidimos coger el transporte público. Evidentemente, no siempre es tan sencillo.

Sin embargo, cuando nos trasladamos al entorno corporativo, empezamos con la tolerancia al riesgo, los criterios de probabilidad, impacto y vulnerabilidad, los catálogos de amenazas (estándar), las estrategias, los registros de riesgo, el riesgo inherente, residual y proyectado, los ratios de mitigación. Y nos perdemos durante meses en conceptos, documentos y metodologías, alejándonos cada vez más de la realidad que tenemos que analizar y proteger.

La ortodoxia en la gestión de riesgos (de ciberseguridad)

A raíz de esto, hace ya unos meses, en plena pandemia, fui a topar con un interesante artículo que contraponía dos visiones muy diferentes de la gestión de riesgos, que venía a llamar RM1 vs RM2.

Básicamente, y citando directamente del artículo, RM1 estaría enfocado a la “gestión de riesgos para las partes interesadas externas (Consejo, auditores, reguladores, gobierno, agencias de calificación crediticia, compañías de seguros y bancos)“, mientras que RM2 sería la “gestión de riesgos para los responsables de la toma de decisiones dentro de la empresa“.

Algunas semanas o meses después, Román Ramírez publicaba una entrada en una línea similar, criticando la ortodoxia reinante en la gestión de riesgos de ciberseguridad y los problemas que esta generaba.

[Read more…]

Purple Team: ¿pero esto qué es? (I)

A menudo leemos o escuchamos términos como Red, Blue, Purple, Adversarial Emulation y muchas otras de forma casi intercambiable, lo que produce confusión en la gente que se aproxima a este mundo.

Todas estas disciplinas, a menudo solapadas parcialmente entre ellas en su ámbito de aplicación, tienen su lugar en el plan de seguridad de una organización, pero conviene tener claros sus puntos fuertes y débiles para aprovechar los primeros y minimizar los segundos.

A lo largo de este artículo, o serie de ellos (a ver hasta donde me lleva la madriguera del conejo), intentaré aportar mi granito de arena en este tema haciendo una introducción al tema y detallando después con algo más de profundidad la metodología Purple Team.

Es conveniente aclarar que este artículo no pretende sentar cátedra sobre el asunto y solo tiene como objetivo hacer una exposición didáctica y lo menos árida posible.

Algunos antecedentes

Según las organizaciones han ido madurando y la ciberseguridad va cobrando importancia, se han ido implementando diferentes metodologías y enfoques.

Hace bastantes años (y desgraciadamente también en algunas organizaciones actualmente) la ciberseguridad se reducía a medidas de hardening (bastionado), y gradualmente se empezaron a desarrollar tecnologías de detección y respuesta.

[Read more…]