it-swarm-es.com

La cuenta de GitLab hackeada y el repositorio borrado

Estaba trabajando en un proyecto, ¡un repositorio privado, y de repente todas las confirmaciones desaparecieron y fueron reemplazadas por un solo archivo de texto que decía

Para recuperar su código perdido y evitar que se filtre: Envíenos 0.1 Bitcoin (BTC) a nuestra dirección de Bitcoin 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA y contáctenos por correo electrónico a [email protected] con su inicio de sesión de Git y un comprobante de pago. Si no está seguro de si tenemos sus datos, contáctenos y le enviaremos una prueba. Su código es descargado y respaldado en nuestros servidores. Si no recibimos su pago en los próximos 10 días, haremos público su código o los usaremos de otra manera.

En el momento en que esto sucedió, la búsqueda de Google no mostró nada, pero en una hora más o menos esto comenzó a aparecer.

Estoy usando SourceTree (siempre actualizado) pero de alguna manera dudo que SourceTree sea el problema o que mi sistema (Windows 10) se haya visto comprometido. No digo que no sea eso, es solo que lo dudo.

Esto le sucedió solo a uno de mis repositorios (todos ellos privados) y todos los demás quedaron intactos. Cambié mi contraseña, habilité la autenticación de 2 factores, eliminé un token de acceso que no estaba usando durante años y escribí un correo electrónico a GitLab con la esperanza de que pudieran decirme algo sobre dónde/quién entró el atacante.

Mi contraseña era débil y podría haberse descifrado con relativa facilidad a través de la fuerza bruta (no es común, pero comienza con "a" y solo tiene caracteres az) y podría ser que simplemente verificaron automáticamente si pueden acceder a la cuenta y luego ejecutar algunos comandos git. También es posible que mi dirección de correo electrónico y esa contraseña en particular estén en una lista de cuentas filtradas. Uno podría argumentar que si así fue como entraron, simplemente habrían cambiado las credenciales de la cuenta, pero la búsqueda en Internet reveló que en estos casos GitLab/GitHub simplemente restaurará las credenciales para usted, por lo que supongo que es por eso que no lo hicieron. No lo hagas de esta manera.

También podría haber sido ese token de acceso antiguo, no puedo recordar para qué y dónde lo usé en el pasado, probablemente generado para usar en una computadora que poseía anteriormente, así que dudo que ese sea el problema.

También hay 4 desarrolladores trabajando en él, todos con acceso total al repositorio, por lo que sus cuentas en peligro también es una posibilidad.

Escaneé mi computadora con BitDefender y no pude encontrar nada, pero no estoy haciendo cosas sospechosas en Internet, así que no creo que me haya infectado con un malware/troyano.

Estoy esperando una respuesta de GitLab y tal vez puedan arrojar algo de luz sobre esto. Tengo la base del código en mi Git local, así que eso no es un problema, pero todavía no estoy enviando el código al repositorio. Además, en caso de que el código se publique en alguna parte, cambiaré las contraseñas que se encuentran en la fuente (bases de datos, cuentas IMAP)

[~ # ~] actualización [~ # ~]

Descubrí que el código no se ha ido. Intenté acceder al hash de commit y funcionó. Entonces el código está ahí, pero hay algo mal con el HEAD. Mi conocimiento sobre esto es muy limitado pero

git reflog

muestra todos mis commits.

Lo que esto significa ¡para mí es que los atacantes probablemente no clonaron los repositorios (de todos modos, sería una pesadilla logística para hacer esto para todas las víctimas) y que las posibilidades de que se trasladen el código fuente que busca datos confidenciales, o de hacer público el código es bajo. También significa para mí que no es un ataque dirigido sino un ataque aleatorio y masivo, realizado por un script. ¡Realmente espero que este sea el caso por nuestro propio bien!

ACTUALIZACIÓN 2

Entonces, si lo haces

git checkout Origin/master

verás el commit del atacante

git checkout master

verás todos tus archivos

git checkout Origin/master
git reflog # take the SHA of the last commit of yours
git reset [SHA]

arreglará tu origen/maestro ... pero

git status

ahora dirá

HEAD detached from Origin/master

sigo buscando una solución para esto

ACTUALIZACIÓN 3

Si tiene los archivos localmente, ejecute

git Push Origin HEAD:master --force

arreglará todo. Ver comentario de Peter

Entonces, la pregunta es qué comandos harán que mi repositorio vuelva al estado de funcionamiento anterior, suponiendo que no tenga el repositorio localmente, en cuanto a cómo entró el atacado, espero que la respuesta de GitLab (si la hubiera) nos ayude más.

Hay una discusión en curso aquí

El ataque apunta a las cuentas de GitHub, BitBucket y GitLab. Aquí 's la magnitud en repositorios públicos de GitHub

166
Stefan Gabos

Puedes usar git reflog en un clon y verifica el último commit antes de que esto sucediera.

Sucedió porque .git/config en su servidor web (en el directorio del repositorio clonado) incluye las URL remotas y el nombre de usuario agregado de la gente: contraseña que nunca debería ser el caso; las personas deberían usar SSH, implementar claves o autenticarse en cada extracción. Nunca almacene sus credenciales en un archivo de configuración. Use la (s) ayuda (s) de credenciales.

Fuente: https://www.reddit.com/r/git/comments/bk1eco/comment/emg3cxg

hola, soy yo, el tipo con tus copias de seguridad ...

revelaré tus pecados

Aquí hay un artículo de 2015, más detallado, https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis -of-alexas-1m-28-07-2015 /

Artículo de Internetwache sobre esto: https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas- 1m-28-07-2015 /

Para evitar que esto bloquee el acceso a los directorios que comienzan con un punto, consulte https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess#L528-L551

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# Block access to all hidden files and directories with the exception of
# the visible content from within the `/.well-known/` hidden directory.
#
# These types of files usually contain user preferences or the preserved
# state of an utility, and can include rather private places like, for
# example, the `.git` or `.svn` directories.
#
# The `/.well-known/` directory represents the standard (RFC 5785) path
# prefix for "well-known locations" (e.g.: `/.well-known/manifest.json`,
# `/.well-known/keybase.txt`), and therefore, access to its visible
# content should not be blocked.
#
# https://www.mnot.net/blog/2010/04/07/well-known
# https://tools.ietf.org/html/rfc5785

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} "!(^|/)\.well-known/([^./]+./?)+$" [NC]
    RewriteCond %{SCRIPT_FILENAME} -d [OR]
    RewriteCond %{SCRIPT_FILENAME} -f
    RewriteRule "(^|/)\." - [F]
</IfModule>

O separe el .git directorio y los datos usando --separate-git-dir.

--separate-git-dir = <git dir>
En lugar de inicializar el repositorio como un directorio para $ GIT_DIR o ./.git/, cree allí un archivo de texto que contenga la ruta al repositorio real. Este archivo actúa como un enlace simbólico de Git independiente del sistema de archivos al repositorio.

Si esto es reinicialización, el repositorio se moverá a la ruta especificada.

Pero lo mejor es rm -rf .git después de una implementación, que simplemente debe copiar un artefacto de compilación en el destino usando rsync.

https://git-scm.com/docs/git-init#Documentation/git-init.txt---separate-git-dirltgitdirgt

--separate-git-dir = <git dir>
En lugar de colocar el repositorio clonado donde se supone que debe estar, coloque el repositorio clonado en el directorio especificado, luego haga un enlace simbólico Git independiente del sistema de archivos. El resultado es que el repositorio de Git se puede separar del árbol de trabajo.

https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---separate-git-dirltgitdirgt

https://stackoverflow.com/a/8603156/753676

Información sobre las claves de implementación y los ayudantes de credenciales:

https://developer.github.com/v3/guides/managing-deploy-keys/

Las claves de implementación son de solo lectura de forma predeterminada, pero puede darles acceso de escritura al agregarlas a un repositorio.

https://Gist.github.com/zhujunsan/a0becf82ade50ed06115

https://help.github.com/en/articles/caching-your-github-password-in-git

Utilizar git Push -u Origin master -f && git Push --tags -f desde su clon local para empujar todas las referencias de master, etiquetas, etc. al control remoto y luego habilitar 2FA en su cuenta.

Si hay más ramas afectadas, use git Push -u --all -f

Además, habilite 2FA para disminuir la posibilidad de tales ataques.

No olvide cambiar todos los inicios de sesión/contraseñas comprometidos y revocar las sesiones desconocidas.

77
Daniel Ruf

Dudo que los piratas informáticos hayan enviado una confirmación de "eliminar todo", o de lo contrario podrías simplemente revertir la última confirmación. Por el contrario, forzaron un commit diferente con la nota al HEAD de la rama maestra, haciendo que parezca que todo su historial de commit se ha ido.

Como otros han señalado, puede usar fácilmente un repositorio local para forzar el envío del código correcto al servidor. Debido a la naturaleza distribuida de Git, esto siempre funciona independientemente de si el servidor se borró o no, ya que cada repositorio local tiene un clon completo del servidor, incluidos los compromisos y el código. Por supuesto, debe asegurarse de que el servidor haya sido protegido antes de intentar los esfuerzos de recuperación. :-)

Si no tiene un repositorio local que incluya la confirmación más reciente, el historial de confirmación (y todos los archivos asociados) seguirán existiendo en el servidor durante un tiempo. Sin embargo, el servidor eventualmente ejecutará git gc, que limpiará esas confirmaciones inalcanzables. A partir de 2013, GitHub dijo que correrán git gc como máximo na vez al día pero también puede ser activado manualmente , mientras que BitBucket lo hará ejecutarlo según sea necesario , o tal vez después de cada Empuje . GitLab lo ejecuta después de 200 pulsaciones por defecto, o puede activarse manualmente.

Sin embargo, incluso si todos los commits y archivos todavía están en el servidor, necesitará encontrar el hash del commit para poder restaurarlo. Sin un repositorio local con un reflog, es difícil encontrar la confirmación correcta para restaurar. Algunas ideas que puedes probar:

  • Las solicitudes de extracción generalmente se guardan para siempre, por lo que debería poder ver la solicitud de extracción más reciente fusionada en la rama maestra. Solo asegúrese de elegir el hash de la confirmación de fusión, no el hash de la rama. (GitHub tiene una marca de verificación verde al lado del hash de confirmación de fusión, GitLab muestra "fusionado en maestro con", no estoy seguro acerca de BitBucket).
  • Si tiene un servidor de compilación, vea cuál fue la compilación más reciente de la rama maestra (¿tal vez en el registro de compilación?)
  • Es posible que también desee verificar los tenedores de su repositorio. GitHub le permite verlos en las vistas de Forks o Network.

Una vez que encuentre el hash correcto para master, puede restaurar su servidor usando los siguientes comandos (suponiendo que tenga un control remoto Git llamado 'Origin').

git fetch Origin <hash>
git checkout master
git reset --hard <hash>
git Push --force Origin master:master

Tenga en cuenta que debe nunca usar git Push --force a menos que tenga la intención de sobrescribir el trabajo de alguien.

49
Matt

Si se ven afectadas más ramas, es posible que primero deba verificar todas las ramas con el siguiente comando antes de realizar git Push -u --all -f

for branch in `git branch -a | grep remotes | grep -v HEAD | grep -v master `; do
   git branch --track ${branch#remotes/Origin/} $branch
done

https://Gist.github.com/octasimo/66f3cc230725d1cf1421

6
Ron

Supongo que ya sabes lo más obvio, pero sin embargo:

  1. En el futuro, configure SSH para comunicarse con GitLab (y cualquier otro control remoto que lo soporte, en realidad) en lugar de nombre de usuario + contraseña, como - @ Daniel Ruf ha aconsejado.

  2. Configure una contraseña muy segura (en el orden de más de 16 caracteres generados aleatoriamente) para su cuenta de GitLab, y use un administrador de contraseñas para administrarlo.

  3. Asegúrese de que su computadora no esté comprometida . Iría un paso más allá y cambiaría las contraseñas de todas mis cuentas en línea por si acaso.

Ahora para abordar otro asunto apremiante:

Lo que esto significa para mí es que los atacantes probablemente no clonaron los repositorios (de todos modos, sería una pesadilla logística hacer esto para todas las víctimas) (supuesto # 1)
(...)
y que las posibilidades de que revisen el código fuente en busca de datos confidenciales o de hacer público el código son bajas (...) (supuesto # 2)

También significa para mí que no es un ataque dirigido, sino un ataque aleatorio y masivo, realizado por un script (...) (supuesto # 3)

Las suposiciones n. ° 1 y n. ° 3 pueden ser ciertas o no (personalmente no creo que sea una pesadilla logística en absoluto clonar repositorios cuando su plan es desfigurarlos para el rescate; el atacante puede tener un servidor dedicado para esa tarea, configurado a través de una VPN o similar. Y podría ser que usted ¡estaba apuntado). Pero no son muy cruciales.

Sin embargo, el supuesto # 2 es uno que no puede permitirse hacer en este momento .

Si el código o el historial del repositorio contenía información privada o algún tipo de secreto comercial, comience a tomar medidas de contingencia de inmediato.

Para citar parte de su mensaje:

Si no recibimos su pago en los próximos 10 días, haremos público su código o los usaremos de otra manera.

Me temo que es seguro que asumas que lo harán tanto si pagas el rescate como si no . Especialmente el bit "úsalas de otra manera".

3
Marc.2377