it-swarm-id.com

Akun GitLab diretas dan repo dihapus

Saya sedang mengerjakan sebuah proyek, repo pribadi, dan tiba-tiba semua komit menghilang dan diganti dengan satu file teks yang mengatakan

Untuk memulihkan kode Anda yang hilang dan menghindari membocorkannya: Kirimkan kami 0,1 Bitcoin (BTC) ke alamat Bitcoin kami 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA dan hubungi kami melalui Email di [email protected] dengan Git login dan Bukti Pembayaran. Jika Anda tidak yakin apakah kami memiliki data Anda, hubungi kami dan kami akan mengirimkan bukti kepada Anda. Kode Anda diunduh dan dicadangkan di server kami. Jika kami tidak menerima pembayaran Anda dalam 10 Hari ke depan, kami akan membuat kode Anda publik atau menggunakannya sebaliknya.

Pada saat ini terjadi, pencarian Google tidak muncul apa-apa, tetapi dalam satu jam atau lebih ini mulai muncul.

Saya menggunakan SourceTree (selalu terbaru) tetapi entah bagaimana saya ragu SourceTree adalah masalahnya, atau bahwa sistem saya (Windows 10) terganggu. Saya tidak mengatakan itu bukan itu, hanya saja saya meragukannya.

Ini hanya terjadi pada salah satu repositori saya (semuanya pribadi) dan yang lainnya tidak tersentuh. Saya mengubah kata sandi saya, mengaktifkan otentikasi 2 faktor, menghapus satu token akses yang tidak saya gunakan selama bertahun-tahun dan menulis email ke GitLab dengan harapan mereka bisa memberi tahu saya tentang di mana/siapa penyerang masuk.

Kata sandi saya adalah kata sandi yang lemah yang bisa dengan mudah dipecahkan melalui brute-force (ini bukan kata yang umum tetapi dimulai dengan "a" dan hanya memiliki karakter az di dalamnya) dan bisa jadi mereka hanya secara otomatis memeriksa jika mereka dapat mengakses akun dan kemudian menjalankan beberapa perintah git. Mungkin juga alamat email saya dan kata sandi tertentu ada dalam daftar akun yang bocor. Orang mungkin berpendapat bahwa jika ini adalah bagaimana mereka masuk, mereka hanya akan mengubah kredensial akun tetapi mencari di internet mengungkapkan bahwa dalam kasus ini GitLab/GitHub hanya akan mengembalikan kredensial untuk Anda, dan jadi saya menganggap ini adalah alasan mengapa mereka tidak melakukannya. lakukan dengan cara ini.

Bisa juga token akses lama itu, saya tidak ingat apa dan di mana saya menggunakannya di masa lalu - kemungkinan besar dihasilkan untuk digunakan pada komputer yang saya miliki sebelumnya, jadi saya ragu bahwa itu masalahnya.

Ada juga 4 pengembang yang mengerjakannya, semua memiliki akses penuh ke repositori, sehingga akun mereka yang dikompromikan juga kemungkinan.

Saya telah memindai komputer saya dengan BitDefender dan tidak dapat menemukan apa pun, tetapi saya tidak melakukan hal-hal yang teduh di internet sehingga saya tidak berpikir bahwa saya terinfeksi malware/trojan adalah penyebabnya.

Saya menunggu jawaban dari GitLab dan mungkin mereka bisa menjelaskan ini. Saya memiliki basis kode pada Git lokal saya, jadi itu bukan masalah, tapi saya belum mendorong kode kembali ke repositori dulu. Juga, kalau-kalau kode diterbitkan di suatu tempat, saya akan mengubah kata sandi yang ditemukan di sumber (database, akun IMAP)

[~ # ~] pembaruan [~ # ~]

Saya menemukan bahwa kode itu tidak hilang. Saya mencoba mengakses hash komit dan berhasil. Jadi kodenya ada tapi ada yang salah dengan KEPALA. Pengetahuan saya tentang ini sangat terbatas tetapi

git reflog

menunjukkan semua komitmen saya.

Apa artinya ini untuk saya adalah bahwa para penyerang kemungkinan besar tidak mengkloning repositori (akan menjadi mimpi buruk logistik untuk melakukan ini untuk semua korban, tetap) dan bahwa peluang bagi mereka untuk pergi kode sumber mencari data sensitif, atau membuat kode publik rendah. Ini juga berarti untuk saya itu bukan serangan yang ditargetkan tetapi serangan massal acak, yang dilakukan oleh skrip. Saya sangat berharap ini terjadi untuk kita sendiri!

PEMBARUAN 2

Jadi, jika Anda melakukannya

git checkout Origin/master

anda akan melihat komit penyerang

git checkout master

anda akan melihat semua file Anda

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

akan memperbaiki Asal/master Anda ... tetapi

git status

sekarang akan berkata

HEAD detached from Origin/master

masih mencari perbaikan untuk ini

PEMBARUAN 3

Jika Anda memiliki file secara lokal, jalankan

git Push Origin HEAD:master --force

akan memperbaiki semuanya. Lihat Peter komentar

Jadi, pertanyaannya adalah perintah apa yang akan membuat repositori saya kembali ke keadaan bekerja sebelumnya dengan asumsi Anda tidak memiliki repo secara lokal, seperti untuk bagaimana serangan itu masuk, saya berharap jawaban dari GitLab (jika ada) akan membantu kami lebih.

Ada diskusi yang sedang terjadi di sini

Serangan itu menargetkan akun GitHub, BitBucket dan GitLab. Di Sini besarnya di repositori publik GitHub

166
Stefan Gabos

Kamu bisa menggunakan git reflog dalam klon dan checkout komit terakhir sebelum ini terjadi.

Itu terjadi karena .git/config pada server web Anda (dalam direktori repo kloning) menyertakan URL jarak jauh dan orang-orang menambahkan nama pengguna: kata sandi di dalamnya yang seharusnya tidak pernah terjadi - orang harus menggunakan SSH, menggunakan kunci atau mengotentikasi pada setiap tarikan. Jangan pernah menyimpan kredensial Anda dalam file konfigurasi. Gunakan pembantu kredensial.

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

halo, ini aku, lelaki dengan cadanganmu ..

saya akan mengungkapkan dosa-dosa Anda

Ini adalah artikel dari tahun 2015, yang lebih rinci, https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis -of-alexas-1m-28-07-2015 /

Artikel oleh Internetwache tentang hal ini: https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas- 1m-28-07-2015 /

Untuk mencegah hal ini memblokir akses ke direktori yang dimulai dengan titik, lihat 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>

Atau pisahkan .git direktori dan data menggunakan --separate-git-dir.

--separate-git-dir = <git dir>
Alih-alih menginisialisasi repositori sebagai direktori ke $ GIT_DIR atau ./.git/, buat file teks di sana yang berisi path ke repositori yang sebenarnya. File ini bertindak sebagai tautan simbolis filesystem-agnostic Git ke repositori.

Jika ini adalah inisialisasi ulang, repositori akan dipindahkan ke jalur yang ditentukan.

Tetapi yang terbaik adalah rm -rf .git setelah penyebaran - yang seharusnya hanya menyalin artefak build ke tujuan menggunakan rsync.

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

--separate-git-dir = <git dir>
Alih-alih menempatkan repositori yang dikloning di tempat yang seharusnya, letakkan repositori yang dikloning pada direktori yang ditentukan, kemudian buat tautan simbolik Git filesystem-agnostik ke sana. Hasilnya adalah repositori Git dapat dipisahkan dari pohon kerja.

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

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

Informasi tentang kunci penyebaran dan bantuan kredensial:

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

Menyebarkan kunci hanya-baca secara default, tetapi Anda bisa memberinya akses tulis saat menambahkannya ke repositori.

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

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

Gunakan git Push -u Origin master -f && git Push --tags -f dari klon lokal Anda ke Push semua referensi untuk master, tag dan seterusnya ke remote dan kemudian aktifkan 2FA di akun Anda.

Jika lebih banyak cabang yang terpengaruh gunakan git Push -u --all -f

Aktifkan juga 2FA untuk mengurangi kemungkinan serangan semacam itu.

Harap jangan lupa untuk mengubah semua login/kata sandi yang dikompromikan dan mencabut setiap sesi yang tidak dikenal.

77
Daniel Ruf

Saya ragu para peretas mendorong komit "hapus semua", atau Anda bisa mengembalikan komit terakhir. Sebaliknya, mereka memaksa-paksa komit yang berbeda dengan catatan ke HEAD dari cabang master, membuatnya terlihat seperti seluruh sejarah komit Anda hilang.

Seperti yang telah ditunjukkan orang lain, Anda dapat dengan mudah menggunakan repo lokal untuk memaksa Push kode yang benar ke server. Karena sifat didistribusikan dari Git, ini selalu berfungsi baik server dihapus atau tidak karena setiap repo lokal memiliki klon lengkap server, termasuk komit dan kode. Tentu saja, Anda harus memastikan server telah diamankan terlebih dahulu sebelum mencoba upaya pemulihan. :-)

Jika Anda tidak memiliki repo lokal yang menyertakan komit terbaru, riwayat komit (dan semua file terkait) akan tetap ada di server untuk sementara waktu. Namun, server pada akhirnya akan berjalan git gc, yang akan membersihkan komitmen yang tidak dapat dijangkau itu. Pada 2013, GitHub mengatakan mereka akan menjalankan git gc paling banyak sekali per hari tetapi bisa juga dipicu secara manual , sementara BitBucket akan jalankan sesuai kebutuhan , atau mungkin setelah setiap Push . GitLab menjalankannya setelah 200 push secara default, atau dapat dipicu secara manual.

Namun, meskipun semua komit dan file masih ada di server, Anda harus mencari hash dari commit sehingga Anda dapat mengembalikannya. Tanpa repo lokal dengan reflog, sulit untuk menemukan komit yang benar untuk dipulihkan. Beberapa ide yang bisa Anda coba:

  • Permintaan tarikan biasanya disimpan selamanya, jadi Anda harus dapat melihat permintaan tarikan paling baru yang digabungkan ke cabang master. Pastikan untuk memilih hash dari gabungan komit, bukan hash cabang. (GitHub memiliki tanda centang hijau di sebelah hash gabungan, GitLab menunjukkan "digabung menjadi master dengan", tidak yakin tentang BitBucket).
  • Jika Anda memiliki server build, lihat apa build terbaru dari cabang master (mungkin di log build?)
  • Anda mungkin ingin memeriksa garpu repo Anda juga. GitHub memungkinkan Anda untuk melihatnya di Forks atau Network view.

Setelah Anda menemukan hash yang tepat untuk master, Anda dapat memulihkan server Anda menggunakan perintah berikut (dengan asumsi Anda memiliki remote Git yang disebut 'Asal').

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

Perhatikan bahwa Anda seharusnya tidak pernah menggunakan git Push --force kecuali jika Anda bermaksud menimpa pekerjaan seseorang.

49
Matt

Jika lebih banyak cabang terpengaruh, Anda mungkin perlu checkout semua cabang terlebih dahulu dengan perintah berikut sebelum melakukan 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

Saya kira Anda sudah tahu yang lebih jelas, namun demikian:

  1. Ke depan, atur SSH untuk berkomunikasi dengan GitLab (dan remote lainnya yang mendukungnya, dalam hal ini) alih-alih nama pengguna + kata sandi, seperti - @ Daniel Ruf telah memberi saran.

  2. Konfigurasikan kata sandi yang sangat kuat (sesuai urutan 16+ karakter yang dihasilkan secara acak) untuk akun GitLab Anda, dan gunakan pengelola kata sandi untuk mengelolanya.

  3. Pastikan komputer Anda tidak terganggu . Saya akan melangkah lebih jauh dan mengubah kata sandi untuk semua akun online saya untuk berjaga-jaga.

Sekarang untuk mengatasi masalah mendesak lainnya:

Apa artinya ini bagi saya adalah bahwa penyerang kemungkinan besar tidak mengkloning repositori (akan menjadi mimpi buruk logistik untuk melakukan ini untuk semua korban, toh) (asumsi # 1)
(...)
dan bahwa peluang bagi mereka untuk membaca kode sumber mencari data sensitif, atau membuat kode publik menjadi rendah (...) (asumsi # 2)

Ini juga berarti bagi saya bahwa itu bukan serangan yang ditargetkan tetapi serangan massal acak, yang dilakukan oleh skrip (...) (asumsi # 3)

Asumsi # 1 dan # 3 mungkin atau mungkin tidak benar (saya pribadi tidak berpikir itu mimpi buruk logistik sama sekali untuk mengkloning repo ketika rencana Anda adalah untuk menebusnya untuk tebusan - penyerang mungkin memiliki server yang didedikasikan untuk tugas itu, dikonfigurasi melalui VPN atau semacamnya. Dan mungkin Anda sudah bertarget). Tapi mereka tidak terlalu penting.

Namun, asumsi # 2 adalah salah satu yang Anda tidak mampu untuk membuat sekarang .

Jika kode atau riwayat repo berisi informasi pribadi atau rahasia dagang apa pun, mulailah segera mengambil langkah darurat.

Mengutip sebagian dari pesan mereka:

Jika kami tidak menerima pembayaran Anda dalam 10 Hari ke depan, kami akan membuat kode Anda publik atau menggunakannya sebaliknya.

Saya khawatir aman bagi Anda untuk berasumsi mereka akan melakukan itu baik Anda membayar tebusan atau tidak . Khususnya bit "gunakan jika tidak".

3
Marc.2377