web-dev-qa-db-ja.com

GitLabアカウントがハッキングされ、リポジトリがワイプされました

私はプロジェクト、プライベートリポジトリに取り組んでいて、突然すべてのコミットが消え、単一のテキストファイルに置き換えられました。

失われたコードを回復し、漏洩を防ぐには：0.1ビットコイン（BTC）をビットコインアドレス1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DAに送信し、Gitログインと支払い証明書を添えて、admin @ gitsbackup.comに電子メールでお問い合わせください。データがあるかどうかわからない場合は、お問い合わせください。証拠をお送りします。コードがダウンロードされ、サーバーにバックアップされます。 10日以内にお支払いがない場合は、コードを公開するか、その他の方法で使用します。

このとき、Google検索は何も表示されませんでしたが、1時間ほどで this が表示され始めました。

私はSourceTreeを使用しています（常に最新の状態です）が、どういうわけかSourceTreeが問題であるか、私のシステム（Windows 10）が侵害されたのではないかと疑っています。それではない、と言っているのではありません。

これは私のリポジトリの1つ（すべて非公開）でのみ発生し、他のリポジトリはすべて変更されませんでした。私はパスワードを変更し、2要素認証を有効にし、何年も使用していなかった1つのアクセストークンを削除し、GitLabにメールを送って、攻撃者がどこに/誰に侵入したのかを教えてくれることを期待しています。

私のパスワードは、ブルートフォースによって比較的簡単に解読される可能性のある脆弱なものでした（一般的なものではありませんが、「a」で始まり、その中にz文字のみが含まれています）。アカウントにアクセスし、いくつかのgitコマンドを実行しました。また、私のメールアドレスとその特定のパスワードが漏洩したアカウントのリストに含まれている可能性もあります。これが彼らの侵入方法である場合、彼らはアカウントの資格情報を変更しただけであると主張するかもしれませんが、インターネットを検索すると、これらのケースではGitLab/GitHubが単に資格情報を復元するだけであることがわかりました。このようにしないでください。

その古いアクセストークンであった可能性もあり、過去に何をどこで使用したのか思い出せません。以前所有していたコンピューターで使用するために生成された可能性が高いため、問題だったのではないかと思います。

また、4人の開発者が作業しており、すべてリポジトリへのフルアクセス権があるため、アカウントが侵害されている可能性もあります。

BitDefenderでコンピューターをスキャンしましたが、何も見つかりませんでしたが、インターネットで怪しいことをしていないので、マルウェア/トロイの木馬に感染していることが原因ではないと思います。

私はGitLabからの回答を待っています。多分彼らはこれに光を当てることができます。私はローカルGitにコードベースを持っているので、それは問題ではありませんが、まだコードをリポジトリにプッシュしていません。また、コードがどこかに公開された場合に備えて、ソース（データベース、IMAPアカウント）で見つかるすべてのパスワードを変更します

[〜＃〜]更新[〜＃〜]

コードが消えていないことがわかりました。コミットのハッシュにアクセスしてみましたが、うまくいきました。したがって、コードはありますが、HEADに問題があります。これに関する私の知識は非常に限られていますが、

git reflog

すべてのコミットを表示します。

これが意味することは、攻撃者がリポジトリを複製しなかった可能性が最も高いことです（とにかく、すべての被害者に対してこれを行うことはロジスティックな悪夢となるでしょう）。機密データを探してソースコードを調べたり、コードを公開したりすることはほとんどありません。また、to meは、標的型攻撃ではなく、ランダムな一括攻撃であり、スクリプトによって実行されます。これが私たち自身のためであることを本当に願っています！

更新2

だから、あなたがするなら

git checkout Origin/master

攻撃者のコミットが表示されます

git checkout master

すべてのファイルが表示されます

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

オリジン/マスターを修正します...しかし

git status

今言う

HEAD detached from Origin/master

まだこれの修正を探しています

更新3

ローカルにファイルがある場合は、

git Push Origin HEAD:master --force

すべてを修正します。 Peter のコメントを参照

したがって、質問は、リポジトリがローカルにない場合、リポジトリが以前の動作状態に戻るコマンドです。攻撃された方法については、GitLab（ある場合）からの回答が役立つことを期待していますもっと。

進行中の議論があります ここ

この攻撃は、GitHub、BitBucket、およびGitLabアカウントを対象としています。 ここ はGitHubの公開レポジトリの大きさです

account-securityransomwareintrusiongithub
166
Stefan Gabos

クローンでgit reflogを使用して、これが発生する前の最後のコミットをチェックアウトできます。

これは、Webサーバー（クローンリポジトリのディレクトリ内）の.git/configにリモートURLが含まれており、ユーザーがユーザー名とパスワードを追加したために発生しました。引く。資格情報を構成ファイルに保存しないでください。資格情報ヘルパーを使用します。

ソース： https://www.reddit.com/r/git/comments/bk1eco/comment/emg3cxg

こんにちは、それは私です。あなたのバックアップを持った男です。

私はあなたの罪を明らかにします

これは2015年の記事で、その詳細は https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis -of-alexas-1m-28-07-2015 /

これに関するInternetwacheの記事： https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas- 1m-28-07-2015 /

これを防ぐには、ドットで始まるディレクトリへのアクセスをブロックします 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>

または、.gitディレクトリと--separate-git-dirを使用してデータを分離します。

--separate-git-dir = <git dir>
リポジトリを$ GIT_DIRまたは./.git/へのディレクトリとして初期化する代わりに、実際のリポジトリへのパスを含むテキストファイルをそこに作成します。このファイルは、リポジトリへのファイルシステムに依存しないGitシンボリックリンクとして機能します。

これが再初期化の場合、リポジトリは指定されたパスに移動されます。

しかし、最善の方法は、デプロイ後にrm -rf .gitを実行することです。これは、rsyncを使用してビルドアーティファクトを宛先にコピーするだけです。

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

--separate-git-dir = <git dir>
クローンされたリポジトリを本来の場所に配置する代わりに、指定されたディレクトリにクローンされたリポジトリを配置し、そこにファイルシステムに依存しないGitシンボリックリンクを作成します。その結果、Gitリポジトリを作業ツリーから分離できます。

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

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

デプロイキーと認証ヘルパーに関する情報：

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

デプロイキーはデフォルトで読み取り専用ですが、リポジトリに追加するときに書き込みアクセス権を与えることができます。

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

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

ローカルクローンのgit Push -u Origin master -f && git Push --tags -fを使用して、マスター、タグなどのすべての参照をリモートにプッシュし、アカウントで2FAを有効にします。

さらに影響を受けるブランチがある場合は、git Push -u --all -fを使用してください

また、2FAを有効にして、このような攻撃の可能性を減らしてください。

不正使用されたすべてのログイン/パスワードを変更し、不明なセッションを取り消すことを忘れないでください。

77
Daniel Ruf

ハッカーが「すべて削除」コミットをプッシュしたのか、それとも単に最後のコミットを元に戻すことができるのか疑問です。むしろ、マスターブランチのHEADへのメモを付けて別のコミットを強制的にプッシュし、コミット履歴全体がなくなったように見せかけました。

他の人が指摘したように、ローカルリポジトリを使用して、正しいコードをサーバーに強制的にプッシュできます。 Gitの分散性により、すべてのローカルリポジトリにはコミットとコードの両方を含むサーバーの完全なクローンがあるため、サーバーがワイプされているかどうかに関係なく、これは常に機能します。もちろん、復旧作業を行う前に、まずサーバーが保護されていることを確認する必要があります。 :-)

最新のコミットを含むローカルリポジトリがない場合、コミット履歴（および関連するすべてのファイル）はしばらくの間サーバーに存在し続けます。ただし、サーバーは最終的にgit gcを実行し、到達できないコミットをクリーンアップします。 2013年の時点で、GitHubはgit gcを最大で 1日1回 実行する予定であると述べていますが、 手動でトリガー することもできますが、BitBucketは 実行する必要に応じて 、またはおそらく プッシュごと 。 GitLabはそれを実行します 200プッシュ後 デフォルトで、または手動でトリガーできます。

ただし、すべてのコミットとファイルがまだサーバー上にある場合でも、コミットのハッシュを見つけて復元できるようにする必要があります。 reflogを含むローカルリポジトリがないと、復元する正しいコミットを見つけるのが困難です。あなたが試すことができるいくつかのアイデア：

  • 通常、プルリクエストは永久に保持されるため、マスターブランチにマージされた最新のプルリクエストを確認できるはずです。ブランチのハッシュではなく、マージコミットのハッシュを選択してください。 （GitHubには、マージコミットハッシュの横に緑色のチェックマークが付いています。GitLabは「マスターにマージされました」と表示しますが、BitBucketについては不明です）。
  • ビルドサーバーがある場合は、masterブランチの最新のビルドを確認します（おそらくビルドログにありますか？）
  • リポジトリのフォークも確認することをお勧めします。 GitHubでは、フォークビューまたはネットワークビューでそれらを表示できます。

マスターの正しいハッシュを見つけたら、次のコマンドを使用してサーバーを復元できます（ 'Origin'と呼ばれるGitリモートがあると仮定します）。

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

誰かの作品を上書きするつもりがない限り、git Push --forceを決して使用しないでください。

49
Matt

より多くのブランチが影響を受ける場合、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

あなたはすでにもっと明白なことを知っていると思いますが、それにもかかわらず：

  1. 今後は、ユーザー名+パスワードの代わりに、GitLab（およびそれをサポートする他のリモート）と通信するために、SSHをセットアップします- @ Daniel Ruf がアドバイスしました。

  2. GitLabアカウントに非常に強力なパスワードを設定します（ランダムに生成された16文字以上の桁数）、およびパスワードマネージャーを使用して管理します。

  3. コンピュータが危険にさらされていないことを確認してください。念のため、さらに一歩進めて、すべてのオンラインアカウントのパスワードを変更します。

次に、別の差し迫った問題に対処します。

これが私に意味することは、攻撃者がリポジトリを複製しなかった可能性が最も高いことです（とにかく、すべての犠牲者のためにこれを行うことはロジスティックな悪夢になるでしょう）。 （仮定＃1）
（...）
そして、機密データを探してソースコードを調べたり、コードを公開したりする可能性は低い（...） （仮定＃2）

それはまた、標的型攻撃ではなく、ランダムな一括攻撃であり、スクリプトによって実行されることも意味します（...） （仮定＃3）

仮定＃1と＃3は当てはまる場合とそうでない場合があります（個人的には、身代金目的でそれらを改ざんすることを計画している場合、リポジトリを複製することはロジスティックな悪夢ではないと私は個人的には考えていません-攻撃者はそのタスク専用のサーバーを持っている可能性があり、 VPNまたはソートを介して構成されます。そして、あなたがターゲットにされたしかし、それらはそれほど重要ではありません。

ただし、仮定＃2は、現時点で作成する余裕がないものです。

コードまたはレポ履歴に個人情報または何らかの企業秘密が含まれている場合は、緊急時の対策をすぐに開始してください。

メッセージの一部を引用するには：

10日以内にお支払いがない場合は、コードを公開するか、その他の方法で使用します。

身代金を支払うかどうかにかかわらず、あなたがそうすることは安全だと思います。特に「他の方法で使用する」ビット。

3
Marc.2377