Compte GitLab piraté et repo effacé
Je travaillais sur un projet, un dépôt privé, et tout à coup tous les commits ont disparu et ont été remplacés par un seul fichier texte disant
Pour récupérer votre code perdu et éviter de le divulguer: envoyez-nous 0,1 Bitcoin (BTC) à notre adresse Bitcoin 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA et contactez-nous par e-mail à [email protected] avec votre identifiant Git et une preuve de paiement. Si vous ne savez pas si nous avons vos données, contactez-nous et nous vous enverrons une preuve. Votre code est téléchargé et sauvegardé sur nos serveurs. Si nous ne recevons pas votre paiement dans les 10 prochains jours, nous rendrons votre code public ou l'utiliserons autrement.
Au moment de cet événement, la recherche Google n'a rien révélé, mais dans une heure environ this a commencé à apparaître.
J'utilise SourceTree (toujours à jour) mais je doute que SourceTree soit le problème ou que mon système (Windows 10) ait été compromis. Je ne dis pas que ce n'est pas ça, c'est juste que j'en doute.
Cela n'est arrivé qu'à l'un de mes référentiels (tous privés) et tous les autres sont restés intacts. J'ai changé mon mot de passe, activé l'authentification à 2 facteurs, supprimé un jeton d'accès que je n'utilisais pas depuis des années et j'ai écrit un e-mail à GitLab dans l'espoir qu'ils pourraient me dire quelque chose sur où/qui l'attaquant est entré.
Mon mot de passe était un mot de passe faible qui aurait pu être relativement facilement craqué via la force brute (ce n'est pas un mot commun mais commence par "a" et ne contient que des caractères az) et il se pourrait qu'ils vérifient automatiquement s'ils le peuvent accéder au compte, puis exécuté quelques commandes git. Il est également possible que mon adresse e-mail et ce mot de passe particulier figurent sur une liste de comptes ayant fait l'objet d'une fuite. On pourrait faire valoir que si c'est ainsi qu'ils sont entrés, ils auraient simplement changé les informations d'identification du compte, mais la recherche sur Internet a révélé que dans ces cas, GitLab/GitHub restaurera simplement les informations d'identification pour vous, et donc je suppose que c'est pourquoi ils ne l'ont pas fait ne le fais pas de cette façon.
Cela aurait également pu être cet ancien jeton d'accès, je ne me souviens pas à quoi et où je l'ai utilisé dans le passé - très probablement généré pour être utilisé sur un ordinateur que je possédais auparavant, donc je doute que c'était le problème.
Il y a également 4 développeurs qui y travaillent, tous ayant un accès complet au référentiel, donc leurs comptes compromis sont également une possibilité.
J'ai analysé mon ordinateur avec BitDefender et je n'ai rien trouvé, mais je ne fais pas de choses louches sur Internet, donc je ne pense pas que ce soit moi qui ai été infecté par un malware/cheval de Troie.
J'attends une réponse de GitLab et peut-être qu'ils peuvent éclairer cela. J'ai la base de code sur mon Git local, donc ce n'est pas un problème, mais je ne repousse pas encore le code dans le référentiel. Aussi, juste au cas où le code serait publié quelque part, je changerai tous les mots de passe qui se trouvent dans la source (bases de données, comptes IMAP)
[~ # ~] mise à jour [~ # ~]
J'ai découvert que le code n'était pas parti. J'ai essayé d'accéder au hachage d'un commit et cela a fonctionné. Donc, le code est là mais il y a quelque chose qui ne va pas avec la tête. Ma connaissance à ce sujet est très limitée mais
git reflog
montre tous mes engagements.
Ce que cela signifie pour moi est que les attaquants n'ont probablement pas cloné les référentiels (ce serait un cauchemar logistique de le faire pour toutes les victimes, de toute façon) et que les chances pour eux de passer le code source à la recherche de données sensibles ou à rendre le code public est faible. Cela signifie également pour moi qui n'est pas une attaque ciblée mais une attaque aléatoire en masse, exécutée par un script. J'espère vraiment que c'est le cas pour nous-mêmes!
MISE À JOUR 2
Donc, si vous le faites
git checkout Origin/master
vous verrez le commit de l'attaquant
git checkout master
vous verrez tous vos fichiers
git checkout Origin/master
git reflog # take the SHA of the last commit of yours
git reset [SHA]
va réparer votre origine/maître ... mais
git status
va maintenant dire
HEAD detached from Origin/master
toujours à la recherche d'une solution à ce problème
MISE À JOUR 3
Si vous avez les fichiers localement, exécutez
git Push Origin HEAD:master --force
va tout réparer. Voir le commentaire de Peter
Donc, la question est de savoir quelles commandes ramèneront mon référentiel à l'état de travail précédent en supposant que vous n'avez pas le dépôt localement, quant à la façon dont l'attaquant est entré, j'espère que la réponse de GitLab (le cas échéant) nous aidera plus.
Il y a une discussion en cours ici
L'attaque vise les comptes GitHub, BitBucket et GitLab. Ici est la magnitude sur les dépôts publics de GitHub
Vous pouvez utiliser git reflog dans un clone et extraire le dernier commit avant que cela ne se produise.
C'est arrivé parce que .git/config sur votre serveur Web (dans le répertoire du dépôt cloné) comprend les URL distantes et les utilisateurs ajoutés nom d'utilisateur: mot de passe, ce qui ne devrait jamais être le cas - les gens doivent utiliser SSH, déployer des clés ou s'authentifier à chaque pull. Ne stockez jamais vos informations d'identification dans un fichier de configuration. Utilisez les aides d'identification.
Source: https://www.reddit.com/r/git/comments/bk1eco/comment/emg3cxg
bonjour, c'est moi, le gars avec vos sauvegardes ..
je vais révéler tes péchés
Voici un article de 2015, son plus détaillé, https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis -of-alexas-1m-28-07-2015 /
Article d'Internetwache à ce sujet: https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas- 1m-28-07-2015 /
Pour empêcher cela, bloquer l'accès aux répertoires commençant par un point, voir 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>
Ou séparez le .git répertoire et les données utilisant --separate-git-dir.
--separate-git-dir = <git dir>
Au lieu d'initialiser le référentiel en tant que répertoire dans $ GIT_DIR ou ./.git/, créez-y un fichier texte contenant le chemin d'accès au référentiel réel. Ce fichier agit comme un lien symbolique Git indépendant du système de fichiers vers le référentiel.S'il s'agit d'une réinitialisation, le référentiel sera déplacé vers le chemin spécifié.
Mais le mieux est de rm -rf .git après un déploiement - qui devrait simplement copier un artefact de build vers la destination en utilisant rsync.
https://git-scm.com/docs/git-init#Documentation/git-init.txt---separate-git-dirltgitdirgt
--separate-git-dir = <git dir>
Au lieu de placer le référentiel cloné où il est censé se trouver, placez le référentiel cloné dans le répertoire spécifié, puis créez un lien symbolique Git indépendant du système de fichiers vers celui-ci. Le résultat est que le référentiel Git peut être séparé de l'arborescence de travail.
https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---separate-git-dirltgitdirgt
https://stackoverflow.com/a/8603156/753676
Informations sur les clés de déploiement et les assistants d'identification:
https://developer.github.com/v3/guides/managing-deploy-keys/
Les clés de déploiement sont en lecture seule par défaut, mais vous pouvez leur donner un accès en écriture lors de leur ajout à un référentiel.
https://Gist.github.com/zhujunsan/a0becf82ade50ed06115
https://help.github.com/en/articles/caching-your-github-password-in-git
Utilisation git Push -u Origin master -f && git Push --tags -f à partir de votre clone local pour transmettre toutes les références du maître, des balises, etc. à la télécommande, puis activer 2FA dans votre compte.
Si plusieurs branches sont affectées, utilisez git Push -u --all -f
Veuillez également activer 2FA pour réduire la possibilité de telles attaques.
N'oubliez pas de modifier toutes les connexions/mots de passe compromis et de révoquer toutes les sessions inconnues.
Je doute que les pirates aient poussé un commit "supprimer tout", sinon vous pouvez simplement annuler le dernier commit. Au lieu de cela, ils ont forcé un commit différent avec la note à HEAD de la branche master, ce qui donne l'impression que tout votre historique de commit a disparu.
Comme d'autres l'ont souligné, vous pouvez facilement utiliser un dépôt local pour forcer l'envoi du code correct au serveur. En raison de la nature distribuée de Git, cela fonctionne toujours que le serveur soit effacé ou non, car chaque dépôt local a un clone complet du serveur, y compris les validations et le code. Bien sûr, vous devez d'abord vous assurer que le serveur a été sécurisé avant de tenter des efforts de récupération. :-)
Si vous ne disposez pas d'un référentiel local qui inclut la validation la plus récente, l'historique des validations (et tous les fichiers associés) existera toujours sur le serveur pendant un certain temps. Cependant, le serveur finira par exécuter git gc, qui nettoiera ces commits inaccessibles. À partir de 2013, GitHub a déclaré qu'ils exécuteront git gc au maximum ne fois par jour mais il peut également être déclenché manuellement , tandis que BitBucket l'exécutera selon les besoins , ou peut-être après chaque poussée . GitLab l'exécute après 200 pressions par défaut, ou il peut être déclenché manuellement.
Cependant, même si tous les validations et fichiers sont toujours sur le serveur, vous devrez trouver le hachage de la validation afin de pouvoir le restaurer. Sans un dépôt local avec un reflog, il est difficile de trouver le bon commit à restaurer. Quelques idées que vous pourriez essayer:
- Les demandes de tirage sont généralement conservées pour toujours, vous devriez donc pouvoir consulter la demande de tirage la plus récente fusionnée dans la branche principale. Assurez-vous simplement de choisir le hachage de la validation de fusion, pas le hachage de la branche. (GitHub a une coche verte à côté du hachage de validation de fusion, GitLab affiche "fusionné en maître avec", pas sûr de BitBucket).
- Si vous avez un serveur de build, voyez quelle était la build la plus récente de la branche master (peut-être dans le journal de build?)
- Vous pouvez également vérifier les fourches de votre repo. GitHub vous permet de les voir dans les vues Forks ou Network.
Une fois que vous avez trouvé le hachage correct pour master, vous pouvez restaurer votre serveur en utilisant les commandes suivantes (en supposant que vous avez une télécommande Git appelée 'Origin').
git fetch Origin <hash>
git checkout master
git reset --hard <hash>
git Push --force Origin master:master
Notez que vous ne devez jamais utiliser git Push --force sauf si vous avez l'intention d'écraser le travail de quelqu'un.
Si plusieurs branches sont affectées, vous devrez peut-être d'abord extraire toutes les branches avec la commande suivante avant d'exécuter 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
Je suppose que vous connaissez déjà le plus évident, mais néanmoins:
À l'avenir, configurez SSH pour communiquer avec GitLab (et toute autre télécommande qui le prend en charge, d'ailleurs) au lieu de nom d'utilisateur + mot de passe, comme - @ Daniel Ruf a conseillé.
Configurez un mot de passe très fort (de l'ordre de 16+ caractères générés aléatoirement) pour votre compte GitLab, et utilisez un gestionnaire de mots de passe pour le gérer.
Assurez-vous que votre ordinateur n'est pas compromis . Je voudrais aller plus loin et changer les mots de passe de tous mes comptes en ligne au cas où.
Maintenant, pour aborder une autre question urgente:
Ce que cela signifie pour moi, c'est que les attaquants n'ont probablement pas cloné les référentiels (ce serait un cauchemar logistique de le faire pour toutes les victimes, de toute façon) (hypothèse n ° 1)
(...)
et que les chances pour eux de parcourir le code source à la recherche de données sensibles ou de rendre le code public sont faibles (...) (hypothèse n ° 2)Cela signifie aussi pour moi qu'il ne s'agit pas d'une attaque ciblée mais d'une attaque aléatoire et massive, réalisée par un script (...) (hypothèse n ° 3)
Les hypothèses n ° 1 et n ° 3 peuvent ou non être vraies (personnellement, je ne pense pas que ce soit un cauchemar logistique du tout de cloner des dépôts lorsque votre plan est de les défigurer pour obtenir une rançon - l'attaquant pourrait bien avoir un serveur dédié pour cette tâche, configuré via un VPN ou le genre. Et il se pourrait que vous étiez ciblé). Mais ils ne sont pas très cruciaux.
Cependant, l'hypothèse n ° 2 est une hypothèse que vous ne pouvez pas vous permettre de faire pour le moment .
Si le code ou l'historique de mise en pension contenait des informations privées ou tout type de secret commercial, commencez immédiatement à prendre des mesures d'urgence.
Pour citer une partie de leur message:
Si nous ne recevons pas votre paiement dans les 10 prochains jours, nous rendrons votre code public ou l'utiliserons autrement.
J'ai bien peur que vous supposiez qu'ils le feront que vous payiez la rançon ou non . Surtout le bit "use them else".