Hace un par de días publicamos en el blog un write-up sobre una prueba de un CTF basado en una carpeta .git que podéis ver aquí y hoy me gustaría profundizar un poco más en los entresijos de GIT.

Para los despistados, GIT es una herramienta de control de versiones que permite a los desarrolladores trabajar de manera colaborativa mediante el uso de ramas y referencias concretas a momentos actuales en el código.

Logo de git

Como se puede apreciar, dentro de esa carpeta .git (oculta para el usuario) es donde sucede la magia de git y está compuesta principalmente por las siguientes carpetas:

• .git/branches antigua carpeta donde se guardaba información sobre las distintas ramas del repositorio, actualmente se considera deprecada pero se crea por evitar conflictos.

• .git/hooks almacena pequeños scripts que serán ejecutados en distintos momentos, ideales para hacer comprobaciones antes de subir código al repositorio remoto ;)

• .git/info contiene información adicional sobre el repositorio.

• .git/refs actualmente se usa como almacén de referencias dentro del repositorio, esto son tanto las etiquetas de versiones como las distintas ramas de trabajo.

• .git/objects esta es la carpeta más interesante de todas, aquí se almacena la información del repositorio en sí, es decir, aquí es donde se guarda el contenido de los archivos.

No obstante, cabe destacar estos dos archivos:

• config almacena la configuración propia del repositorio, cómo por ejemplo cuales son los repositorios remotos o configuración del usuario, si quieres saber más: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

• HEAD hace referencia a la posición actual en el repositorio, es decir a la rama donde está trabajando (p.ej. master)

¿Cómo almacena git el contenido?

Para entenderlo mejor vamos a realizar una pequeña demo centrada en esa carpeta objects que actualmente está vacía, donde almacena supuestamente git los datos de los archivos en el repositorio. Para ello usaremos el comando git hash-object que es de lo que git hace uso internamente cuando se realiza un commit.

Ahora nuestra carpeta .git/objects ya contiene un archivo, en este caso localizado en .git/objects/eb/d770c4ec1aeb9db7d5cc43fd0186bad6edf022. Cabe destacar el uso de una carpeta con los dos primeros caracteres, esto lo realiza para optimizar las búsquedas en los repositorios en los que existen gran cantidad de objetos.

Si con esto ya se entiende más o menos como gestiona git los datos, vamos a realizar una prueba generando un archivo con dos versiones distintas

Tal y como se puede apreciar, se han generado 2 hashes distintos para un mismo archivo y es que a diferencia de lo que pudiera parecer, git genera un blob de datos  (datos binarios) de tipo objeto por cada contenido de modo que un mismo archivos con distintas versiones aparecerá en la carpeta .git/objects como varios archivos de datos distintos.

Si quisiéramos ver el contenido de uno de estos objetos, se puede usar el comando git cat-file que se encargará de devolvernos el contenido de ese objeto, si usásemos el comando cat nos encontraríamos con contenido binario y comprimido ilegible, os recomiendo hacer una pequeña prueba.

Con este sencillo comando, se puede leer el contenido de los distintos blobs pertenecientes a un repositorio, a destacar el uso de -p para indicarle que interprete el tipo de dato del que se trata, pues ya veremos en posteriores post que puede haber varios.

Ahora dominamos un poco más como se almacena la info en git, a lo largo de esta serie os explicaremos como puede seros útil en un pentest o ejercicio de red team.

Sed buenos y 

¡Feliz viernes!

Para no alargarnos demasiado, haremos un post más en el que os hablaremos de algunos detalles de Hashtopolis que nos han gustado bastante y que no conocíamos inicialmente. ¡Seguro que os interesa! :)

Y vosotros, ¿habéis jugado con Hashtopolis? ¿Qué os parece?

Stay tuned!

Hi everyone!

This last weekend pry0cc, founder of 0x00sec, posted the first challenge of their bi-monthly CTF exercises. The purpose of this is to make very short, 10-30 minute exercises designed to teach you new techniques. Quite cool, isn't it? :P

The first challenge was about a website where you are supposed to log in and get the flag, the description of the challenge says that there are multiple ways to achieve our goal. I will describe in this post how I achieved it and how dangerous could a .git folder be. So let's start!

I started by looking into the source code of the website, looking for any comments or paths in the website that gives me any clue where to go:

Not that easy, of course, but always keep thinking out of the box. Directory listing is forbidden in the server, what about knowing the path to the file? Let's check some like:

We can read files! Cool, lets take some juicy files with the content we already know, like:

We can check that there was just one commit in the master branch. If we try to parse correctly the index git file, we could get the SHA1 hash of the git object related to that commit.

Let's dive a bit in how git stores its objects and how can we use it if we find a website with a .git folder exposed. To illustrate that, I will show you how an /.git/objects folder is structured when you are adding files by git add command:

There are a new file and a directory in objects directory. This is because files, directory structures and commits are stored in objects directory. Index file, has also changed, we can start digging too much into how git works, but it will get a bit out of scope. If you want to know more about how git works, I recommend you to read the documentation ;)

Following with the challenge, if we parse the index file with for example the known tool called: gin, we will get the contents of it easily:

If you have done your homework correctly, you could check that this SHA1 hash is divided into two parts in the previous example of /.git/objects, using the first two characters as a folder and the rest of the hash as the file. So, we need to the get the object and decompress it to see the content :)

Once I got the file I used Python3 and zlib library to decompress it, as it seems to be a tiny file, I just printed it in the Python console:

As this is the first challenge, I supposed that the hash is stored in some of the online databases, I also noticed that the flag is printed by xor_this function, but I was a bit lazy and went by the dictionary path :P

I hope this will help you in the future when you come accross a .git folder exposed, if you liked this post don't forget to share it ;)