The Dirt: Dirty Business Card Reader Curricula Module

Hace un tiempo habló Chema Alonso en este blog del proyecto del equipo de Ideas Locas llamado Dirty Business Card y de cómo sacar información pública en Internet a partir de una tarjeta de visita usando OSINT y algún info-leak. A día dese  sigue dotando a la herramienta de nueva funcionalidad, y como ya es por todos hacer un poco de Hacking con Buscadores permite extraer información con gran facilidad.

Figura 1: The Dirty: Dirty Business Card Reader Curricula Module

En el artículo de hoy os vengo a hablar de cómo estamos dotando a Dirty Business Card de la capacidad de conseguir el currículo de aquellas personas que lo tengan público en la red usando Google. Estas mismas técnicas se pueden - y se deberían - aplicar también usando otros buscadores como Bing o DuckDuckGo.

Figura 2: Libro Hacking con Buscadores 3ª Edición.
Un auténtico clásico para entender OSINT

El proyecto de Dirty Business Card ya cuenta con la búsqueda de información estructura de los curricula usando LinkedIN, pero en este caso queríamos ir a la búsqueda no estructurada de CV que se haya creado en documentos ofimáticos.

Google Hacking para búsqueda de Curricula

Encontrar un Curriculum Vitae nos puede ayudar a encontrar información muy relevante acerca de una persona, como su número de teléfono, su dirección de e-mail personal o dirección postal de residencia. Para llevar a cabo esta tarea, utilizaremos algo de Google Dorks. En la red tenemos muchos idiomas, y como hablamos de información no estructurada, cada CV puede contener un formato diferente, y como es lógico las palabras clave a buscar cambiaran. Veamos un ejemplo en inglés y español.

Ejemplo de búsqueda en inglés

“phone * * *” “address *” “e-mail” intitle:”curriculum vitae”

Como veis, tenemos más de 62.000 resultados, algunos de ellos serán falsos positivos. Muy lejos de los millones de resultados que puede tener un LinkedIN, pero puede que aparezca información muy jugosa.

Figura 3: Búsqueda de CVs en Inglés

Además, nos puede interesar buscar una determinada persona, para ello basta con añadir el nombre y/o apellido que venga en la Business Card a la búsqueda (no olvides las comillas), o filtrar por algún dato que ya tengamos como el número de teléfono o una dirección de correo electrónico.

Ejemplo de búsqueda en español

“teléfono * * *” “dirección *” “e-mail” intitle:”curriculum vitae”

En esta ocasión recibimos menos resultados, pero 18.900, que no es poco. Al igual que en el ejemplo de inglés podemos añadir los datos de la persona buscada en Dirty Business Card, a ver si hay suerte.

Figura 4: Currículos devueltos por la búsqueda

Estas búsquedas son ejemplos, es posible obtener otra consulta con más resultados (mejores o peores), todo es probar y variar la búsqueda, se puede cambiar phone por telephone, por poner un ejemplo.

Dirty Business Card Reader

La herramienta para el backend utiliza el Framework Flask (Python), para las peticiones hacemos uso de requests y para parsear los resultados beautifulsoup. En la parte frontend del proyecto se hace uso de Angular, una tecnología que utilizamos en muchos proyectos en nuestra unidad CDO.

Figura 5: Libro de desarrollo en Angular en 0xWord

El funcionamiento general de Dirty Business Card Reader ya lo habéis visto en el vídeo. Se escanea una tarjeta de visita y el sistema va buscando toda la información que se puede extraer de los datos que van en ella. Aquí tenéis un vídeo de su funcionamiento.

Figura 6: Dirty Business Card Reader

Dentro de Dirty Business Card Reader, se busca a través del nombre y apellidos por posibles CV que encuentra Google, y devolvemos un gráfico con las posibilidades (se ha limitado la información que se devuelve para este ejemplo).

Figura 7: A partir de la Business Card se han encontrado 2 CV en Google

Vemos que a través del nombre se ha encontrado el CV en Internet, y tiene dos posibles resultados. Si pasamos el ratón por encima, se puede ver la URL. Esta es la forma más visual, pero a la hora de trabajar es más fácil el acceso a formato texto, para ello tenemos los resultados en un listado (URLs editadas para eliminar información sobre la persona de ejemplo).

Figura 8: URLs de los CV encontrados

Si vistamos cualquiera de los dos enlaces obtenidos por la herramienta, podemos verificar que se trata de un CV, y que pertenece a la persona indicada (por motivos de privacidad se ha omitido). Nada rocket-science, solo más información que se extrae de tu Business Card si no tienes controlada la información que llevas en ella.

Figura 9: CV encontrado con Dirty Business Card Reader

Según el lado de donde miremos, Google puede ser nuestro mejor aliado, o convertirse en nuestro peor enemigo. Conclusión, controla lo que compartes en Internet, no dejes información sensible accesible al mundo.

¡Hasta pronto!

Autor: Josué Encinar García (@JosueEncinar), autor del blog BoomerNiX y Security Researcher en el equipo de Ideas Locas de la unidad CDO de Telefónica.

Pentesting con PowerShell: Powershell Transcription, Constrained Language y otras medidas de protección en un Ethical Hacking

En el blog hemos hablado de diferentes cosas relacionadas con el pentesting con Powershell. Ya hemos hablado sobre la protección de AMSI y las necesidades de hacer un bypass cuando uno está haciendo Ethical Hacking, sobretodo si hay sistemas Windows 10 por medio. Como nota dejar por aquí una charla y presentación de BlackHat de años anteriores donde se presentaban formas de saltarse AMSI, recomendable su lectura.

Figura 1: Pentesting con PowerShell: Powershell Transcription,
Constrained Language y otras medidas de protección en un Ethical Hacking

El martes 26 daré un RootedLab sobre PowerShell y sus posibilidades ofensivas en un pentest. Los asistentes tendrán un cupón descuento para libros míos de 0xWord. Hoy, quería hablaros sobre las posibilidades de defensa que Powershell ha empezado a tener, ya que no todo es ataque para eso ya tenéis el libro de Pentesting con Powershell 2ª Edición.

Figura 2: Pentesting con Powershell 2ª Edición

Por supuesto, y como digo siempre, cuando sale una protección o una forma de restringir acciones, se investiga la forma de saltarse esa protección. Es una acción natural que ayuda a mejorar la solvencia y potencia de la protección. El juego del gato y del ratón, así que vamos a ver cómo hacer algo de lo que trata el libro de mi compañero Sergio de los Santos, aplicar políticas para alcanzar la "Máxima Seguridad en Windows"

Política de ejecución

La política de ejecución de scripts de Powershell es un concepto que está presenta desde hace mucho tiempo, desde las primeras versiones de Powershell. El objetivo inicial era marca qué se podía ejecutar y en qué ámbito. Un ejemplo sencillo es visualizar lo siguiente:

• Restricted: Política restringida, no se puede ejecutar ningún script de Powershell a través de dicho proceso.
• Unrestricted: Política totalmente no restringida. Se puede ejecutar cualquier script en Powershell.
• RemoteSigned: Se puede ejecutar solo scripts creados localmente y si son remotos o descargados, solo si están firmados.
• Signed: Se pueden ejecutar scripts solo si están firmados.

Aparecieron más políticas y se fue perdiendo el foco. Por ejemplo, hay una política que es ‘Bypass’.

Figura 3: Powershell.exe -Exec Bypass

Con esta política se puede ejecutar un proceso de Powershell, donde el usuario puede ejecutar scripts, simplemente arrancando el proceso con dicha política, por ejemplo: powershell.exe –Bypass.

Constrained Language

Una de las evoluciones para evitar ciertas acciones ‘maliciosas’ fue la llamada Constrained Language o modo de lenguaje restringido. La idea que radica detrás de este modo es poder utilizar o dar soporte a las tareas administrativas del día a día y restringir el acceso a la parte sensible del lenguaje de Powershell. Ese lenguaje que puede ser utilizado para invocar APIs de Windows orientadas a otro tipo de tareas, no tan administrativas.

Aquí tenemos una nueva protección, por lo que tenemos a gente buscando la posibilidad de saltar la protección. ¿El resultado? La mejora de la solución de protección, si se tiene en cuenta que hay vías de saltarla.

Figura 4: Deteccion del tipo de lenguaje

Para ver el tipo de lenguaje que tenemos se puede ejecutar $ExecutionContext.SessionState.LanguageMode. Si el modo de lenguaje se encuentra en Constrained, estaremos ante el modo de lenguaje restringido. Si el sistema base tiene Powershell versión 2, se puede hacer un bypass del CLM, ya que el modo Constrained aparece en la versión 3 de Powershell.

Figura 5: Constrained no está en v2

En Windows 10, desaparece la posibilidad, por defecto, de utilizar Powershell versión 2, por lo que se evita este bypass y debemos ir a otras opciones. Por ejemplo, se puede utilizar PSBypassCLM, una herramienta que permite hacer ese bypass.

Powershell Transcription

No todo es protección directa. En muchas ocasiones nos interesa saber qué es lo que está ocurriendo en el sistema y tener un buen sistema de logging es fundamental. En el caso de Powershell, éste ha ido evolucionando y mejorando. Hay varias opciones:

• Module Logging.
• Script Block Logging.
• Powershell Transcription.

Las tres opciones son funcionalidades para registrar acciones que ocurren a través de Powershell. Module Logging registra el uso de módulos, mientras que la segunda es capaz de registrar comandos, bloques de script o script-block, etcétera. La tercera es una de las más interesantes, ya que registra el input y output de la sesión con Powershell.

¿Dónde se activa esto?

Tenemos que abrir el binario mmc.exe, la consola de gestión de Windows, y añadir un nuevo complemento. El complemento es el objeto de políticas locales. Debemos ir a la parte de “Computer Configuration -> Windows Components -> Windows Powershell”.

Figura 6: Opciones de PowerShell en mmc.exe

Para habilitar Powershell Transcription se debe entrar en la configuración y habilitarla. Es importante seleccionar el directorio donde se quiere almacenar el fichero con los inputs y outputs generados por cualquier usuario a través de una Powershell.

Como se puede ver en la imagen siguiente, el proceso es sencillo y a partir de este momento se dispone de un sistema que registra cualquier acción sobre la Powershell. Esto permitirá, en la mayoría de los casos, registrar acciones sobre lo que hacen los usuarios y poder estudiar y detectar alguna acción “extraña” o alguna ejecución maliciosa.

Figura 7: Política para logging de inputs & outputs en Powershell

Para este ejemplo, podemos ver como el fichero de texto ha registrado las acciones de entrada y salida dentro de una Powershell. Lo que el usuario ejecutó y el resultado que éste obtuvo. Esto ayuda a un administrador a entender bien el entorno en el que se han estado moviendo los usuarios.

Figura 8: registro de acciones

Es importante conocer las defensas de Powershell para poder llevar a cabo la parte ofensiva, sin duda. Microsoft proporciona diferentes medidas de protección, en busca de un entorno lo más seguro posible. Sin duda, es interesante conocer, tanto la parte defensiva como la ofensiva, si te dedicas al pentesting. Powershell sigue evolucionando de la mano de Microsoft.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.