it-swarm-vi.com

Tài khoản GitLab bị hack và repo bị xóa

Tôi đang làm việc trên một dự án, một repo riêng, và đột nhiên tất cả các cam kết biến mất và được thay thế bằng một tệp văn bản duy nhất nói

Để khôi phục mã bị mất của bạn và tránh rò rỉ mã: Gửi cho chúng tôi 0,1 Bitcoin (BTC) đến địa chỉ Bitcoin 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA của chúng tôi và liên hệ với chúng tôi qua Email tại [email protected] với thông tin đăng nhập Git của bạn. Nếu bạn không chắc chắn nếu chúng tôi có dữ liệu của bạn, hãy liên hệ với chúng tôi và chúng tôi sẽ gửi cho bạn một bằng chứng. Mã của bạn được tải xuống và sao lưu trên các máy chủ của chúng tôi. Nếu chúng tôi không nhận được khoản thanh toán của bạn trong 10 ngày tới, chúng tôi sẽ công khai mã của bạn hoặc sử dụng chúng theo cách khác.

Tại thời điểm này xảy ra, tìm kiếm của Google không hiển thị bất cứ điều gì, nhưng trong khoảng một giờ nữa điều này bắt đầu xuất hiện.

Tôi đang sử dụng SourceTree (luôn cập nhật) nhưng bằng cách nào đó tôi nghi ngờ rằng SourceTree là vấn đề hoặc hệ thống của tôi (Windows 10) đã bị xâm phạm. Tôi không nói không phải vậy, chỉ là tôi nghi ngờ điều đó.

Điều này chỉ xảy ra với một trong những kho lưu trữ của tôi (tất cả chúng là riêng tư) và tất cả những kho khác đều bị ảnh hưởng. Tôi đã thay đổi mật khẩu, kích hoạt xác thực 2 yếu tố, xóa một mã thông báo truy cập mà tôi đã không sử dụng trong nhiều năm và viết email cho GitLab với hy vọng họ có thể cho tôi biết điều gì đó về nơi mà kẻ tấn công đã vào.

Mật khẩu của tôi là một mật khẩu yếu, có thể bị bẻ khóa tương đối dễ dàng thông qua vũ lực (nó không phải là thông thường nhưng bắt đầu bằng "a" và chỉ có các ký tự az trong đó) và có thể là chúng chỉ tự động kiểm tra nếu chúng có thể truy cập vào tài khoản và sau đó chạy một số lệnh git. Cũng có thể địa chỉ email của tôi và mật khẩu cụ thể đó nằm trong danh sách các tài khoản bị rò rỉ. Mọi người có thể lập luận rằng nếu đây là cách họ tham gia, họ sẽ đơn giản thay đổi thông tin đăng nhập tài khoản nhưng tìm kiếm trên Internet đã tiết lộ rằng trong những trường hợp này, GitLab/GitHub sẽ khôi phục thông tin đăng nhập cho bạn và vì vậy tôi cho rằng đây là lý do họ đã làm Không làm theo cách này.

Cũng có thể là mã thông báo truy cập cũ đó, tôi không thể nhớ những gì và nơi tôi đã sử dụng nó trong quá khứ - rất có thể được tạo để sử dụng trên máy tính mà tôi sở hữu trước đây, vì vậy tôi nghi ngờ đó là vấn đề.

Ngoài ra còn có 4 nhà phát triển làm việc trên đó, tất cả đều có quyền truy cập đầy đủ vào kho lưu trữ, vì vậy tài khoản của họ bị xâm phạm cũng là một khả năng.

Tôi đã quét máy tính của mình bằng BitDefender và không thể tìm thấy bất cứ thứ gì nhưng tôi không làm những thứ mờ ám trên internet vì vậy tôi không nghĩ rằng tôi bị nhiễm phần mềm độc hại/trojan là nguyên nhân gây ra điều này.

Tôi đang chờ câu trả lời từ GitLab và có lẽ họ có thể làm sáng tỏ điều này. Tôi có cơ sở mã trên Git cục bộ của mình, vì vậy đó không phải là vấn đề, nhưng tôi chưa đẩy mã trở lại kho lưu trữ. Ngoài ra, chỉ trong trường hợp mã được xuất bản ở đâu đó, tôi sẽ thay đổi bất kỳ mật khẩu nào được tìm thấy trong nguồn (cơ sở dữ liệu, tài khoản IMAP)

[~ # ~] cập nhật [~ # ~]

Tôi phát hiện ra rằng mã không biến mất. Tôi đã thử truy cập hàm băm của một cam kết và nó đã hoạt động. Vì vậy, mã ở đó nhưng có gì đó không đúng với ĐẦU. Kiến thức của tôi về điều này rất hạn chế nhưng

git reflog

cho thấy tất cả các cam kết của tôi.

Điều này có nghĩa là gì với tôi là những kẻ tấn công rất có thể đã không sao chép các kho lưu trữ (dù sao cũng sẽ là cơn ác mộng hậu cần để làm điều này cho tất cả các nạn nhân) và đó là cơ hội cho chúng vượt qua mã nguồn tìm kiếm dữ liệu nhạy cảm hoặc làm cho mã công khai ở mức thấp. Nó cũng có nghĩa là với tôi đó không phải là một cuộc tấn công được nhắm mục tiêu mà là một cuộc tấn công ngẫu nhiên, hàng loạt, được thực hiện bởi một tập lệnh. Tôi thực sự hy vọng đây là trường hợp vì lợi ích của chúng ta!

CẬP NHẬT 2

Vì vậy, nếu bạn làm

git checkout Origin/master

bạn sẽ thấy cam kết của kẻ tấn công

git checkout master

bạn sẽ thấy tất cả các tập tin của bạn

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

sẽ sửa lỗi Origin/master của bạn ... nhưng

git status

bây giờ sẽ nói

HEAD detached from Origin/master

vẫn đang tìm cách khắc phục

CẬP NHẬT 3

Nếu bạn có các tệp cục bộ, đang chạy

git Push Origin HEAD:master --force

sẽ sửa chữa mọi thứ. Xem Peter bình luận

Vì vậy, câu hỏi đặt ra là các lệnh nào sẽ đưa kho lưu trữ của tôi trở lại trạng thái hoạt động trước đó, giả sử bạn không có repo cục bộ, như cách thức tấn công, tôi hy vọng rằng câu trả lời từ GitLab (nếu có) sẽ giúp chúng tôi hơn.

Có một cuộc thảo luận đang diễn ra tại đây

Cuộc tấn công nhắm vào các tài khoản GitHub, BitBucket và GitLab. Ở đây là độ lớn trên các repos công khai của GitHub

166
Stefan Gabos

Bạn có thể dùng git reflog trong một bản sao và kiểm tra cam kết cuối cùng trước khi điều này xảy ra.

Nó đã xảy ra vì .git/config trên máy chủ web của bạn (trong thư mục của repo nhân bản) bao gồm các URL từ xa và mọi người đã thêm tên người dùng: mật khẩu không bao giờ được sử dụng - mọi người nên sử dụng SSH, triển khai khóa hoặc xác thực trên mỗi lần kéo. Không bao giờ lưu trữ thông tin đăng nhập của bạn trong một tập tin cấu hình. Sử dụng người trợ giúp thông tin (s).

Nguồn: https://www.reddit.com/r/git/comments/bk1eco/comment/emg3cxg

xin chào, đó là tôi, người có bản sao lưu của bạn ..

tôi sẽ tiết lộ tội lỗi của bạn

Đây là một bài viết từ năm 2015, chi tiết hơn, https://en.i INTERNetwache.org/dont-publicly-expose-git-or-how-we-doaded-your-websites-sourcecode-an-analysis -of-alexas-1m-28-07-2015 /

Bài viết của Internetwache về điều này: https://en.i INTERNetwache.org/dont-publicly-expose-git-or-how-we-doaded-your-websites-sourcecode-an-analysis-of-alexas- 1m-28-07-2015 /

Để ngăn chặn điều này, hãy chặn quyền truy cập vào các thư mục bắt đầu bằng dấu chấm, xem https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htmlaccess#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>

Hoặc tách .git thư mục và dữ liệu sử dụng --separate-git-dir.

--separate-git-dir = <git dir>
[.__.] Thay vì khởi tạo kho lưu trữ dưới dạng thư mục thành $ GIT_DIR hoặc ./.git/, hãy tạo một tệp văn bản ở đó có chứa đường dẫn đến kho lưu trữ thực tế. Tập tin này hoạt động như liên kết tượng trưng Git của hệ thống tập tin đến kho lưu trữ.

Nếu đây là khởi tạo lại, kho lưu trữ sẽ được chuyển đến đường dẫn đã chỉ định.

Nhưng tốt nhất là rm -rf .git sau khi triển khai - chỉ cần sao chép một vật phẩm xây dựng đến đích bằng cách sử dụng rsync.

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

--separate-git-dir = <git dir>
[.__.] Thay vì đặt kho lưu trữ nhân bản ở nơi được cho là, hãy đặt kho lưu trữ nhân bản vào thư mục được chỉ định, sau đó tạo liên kết biểu tượng Git của hệ thống tập tin đến đó. Kết quả là kho Git có thể được tách ra khỏi cây làm việc.

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

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

Thông tin về các khóa triển khai và người trợ giúp thông tin xác thực:

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

Các khóa triển khai được đọc theo mặc định, nhưng bạn có thể cấp cho chúng quyền truy cập ghi khi thêm chúng vào kho lưu trữ.

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

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

Sử dụng git Push -u Origin master -f && git Push --tags -f từ bản sao cục bộ của bạn sang Đẩy tất cả các tham chiếu cho chủ, thẻ, v.v. vào điều khiển từ xa và sau đó bật 2FA trong tài khoản của bạn.

Nếu nhiều chi nhánh bị ảnh hưởng sử dụng git Push -u --all -f

Ngoài ra, vui lòng kích hoạt 2FA để giảm khả năng các cuộc tấn công như vậy.

Xin đừng quên thay đổi tất cả thông tin đăng nhập/mật khẩu bị xâm phạm và thu hồi bất kỳ phiên không xác định nào.

77
Daniel Ruf

Tôi nghi ngờ rằng các tin tặc đã đẩy một cam kết "xóa tất cả", nếu không bạn chỉ có thể hoàn nguyên cam kết cuối cùng. Thay vào đó, họ buộc phải đẩy một cam kết khác với ghi chú vào HEAD của nhánh chính, làm cho nó có vẻ như toàn bộ lịch sử cam kết của bạn đã biến mất.

Như những người khác đã chỉ ra, bạn có thể dễ dàng sử dụng repo cục bộ để buộc Đẩy mã chính xác đến máy chủ. Do tính chất phân tán của Git, điều này luôn hoạt động cho dù máy chủ có bị xóa hay không vì mọi repo cục bộ đều có một bản sao hoàn chỉnh của máy chủ, bao gồm cả cam kết và mã. Tất nhiên, bạn nên đảm bảo rằng máy chủ đã được bảo mật trước khi thử các nỗ lực khôi phục. :-)

Nếu bạn không có repo cục bộ bao gồm cam kết gần đây nhất, lịch sử cam kết (và tất cả các tệp được liên kết) sẽ vẫn tồn tại trên máy chủ trong một thời gian. Tuy nhiên, máy chủ cuối cùng sẽ chạy git gc, sẽ dọn sạch những cam kết không thể truy cập. Kể từ năm 2013, GitHub cho biết họ sẽ chạy git gc nhiều nhất một lần mỗi ngày nhưng cũng có thể là được kích hoạt thủ công , trong khi BitBucket sẽ chạy nó khi cần , hoặc có lẽ sau mỗi lần đẩy . GitLab chạy nó sau 200 lần đẩy theo mặc định hoặc có thể được kích hoạt bằng tay.

Tuy nhiên, ngay cả khi tất cả các cam kết và tệp vẫn còn trên máy chủ, bạn sẽ cần tìm hàm băm của cam kết để bạn có thể khôi phục nó. Nếu không có repo cục bộ với một reflog, thật khó để tìm đúng cam kết để khôi phục. Một số ý tưởng mà bạn có thể thử:

  • Yêu cầu kéo thường được lưu giữ mãi mãi, vì vậy bạn sẽ có thể xem xét yêu cầu kéo gần đây nhất được sáp nhập vào nhánh chính. Chỉ cần đảm bảo chọn hàm băm của cam kết hợp nhất, không phải là hàm băm của nhánh. (GitHub có dấu kiểm màu xanh lục bên cạnh hàm băm cam kết hợp nhất, GitLab hiển thị "được hợp nhất thành chủ", không chắc chắn về BitBucket).
  • Nếu bạn có một máy chủ xây dựng, hãy xem bản dựng gần đây nhất của nhánh chính là gì (có lẽ trong nhật ký xây dựng?)
  • Bạn có thể muốn kiểm tra dĩa của repo của bạn là tốt. GitHub cho phép bạn nhìn thấy chúng trong chế độ xem Fork hoặc Mạng.

Khi bạn tìm thấy hàm băm chính xác cho chủ, bạn có thể khôi phục máy chủ của mình bằng các lệnh sau (giả sử bạn có một điều khiển từ xa Git gọi là 'Origin').

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

Lưu ý rằng bạn nên không bao giờ sử dụng git Push --force trừ khi bạn có ý định ghi đè lên tác phẩm của ai đó.

49
Matt

Nếu nhiều chi nhánh bị ảnh hưởng, bạn có thể cần kiểm tra tất cả các chi nhánh trước bằng lệnh sau trước khi thực hiện 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

Tôi đoán bạn đã biết rõ ràng hơn, nhưng tuy nhiên:

  1. Đi tiếp, thiết lập SSH để liên lạc với GitLab (và bất kỳ điều khiển từ xa nào khác hỗ trợ nó, cho vấn đề đó) thay vì tên người dùng + mật khẩu, như - @ Daniel Ruf đã khuyên.

  2. Định cấu hình mật khẩu rất mạnh (theo thứ tự 16+ ký tự được tạo ngẫu nhiên) cho tài khoản GitLab của bạn và sử dụng trình quản lý mật khẩu để quản lý nó.

  3. Đảm bảo máy tính của bạn không bị xâm phạm . Tôi sẽ tiến thêm một bước và thay đổi mật khẩu cho tất cả các tài khoản trực tuyến của mình chỉ trong trường hợp.

Bây giờ để giải quyết vấn đề cấp bách khác:

Điều này có nghĩa với tôi là những kẻ tấn công rất có thể đã không sao chép các kho lưu trữ (dù sao cũng sẽ là một cơn ác mộng hậu cần để làm điều này cho tất cả các nạn nhân) (giả định số 1)
[.__.] (...)
[.__.] và rằng cơ hội để họ vượt qua mã nguồn tìm kiếm dữ liệu nhạy cảm hoặc khiến mã công khai ở mức thấp (...) (giả định số 2)

Điều đó cũng có nghĩa với tôi đó không phải là một cuộc tấn công có chủ đích mà là một cuộc tấn công ngẫu nhiên, hàng loạt, được thực hiện bởi một kịch bản (...) (giả định số 3)

Giả định số 1 và số 3 có thể đúng hoặc không đúng được định cấu hình qua VPN hoặc sắp xếp. Và có thể là bạn were nhắm mục tiêu). Nhưng chúng không quan trọng lắm.

Tuy nhiên, giả định số 2 là thứ bạn không thể đủ khả năng để thực hiện ngay bây giờ .

Nếu mã hoặc lịch sử repo chứa thông tin cá nhân hoặc bất kỳ loại bí mật thương mại nào, hãy bắt đầu thực hiện các bước dự phòng ngay lập tức.

Để trích dẫn một phần thông điệp của họ:

Nếu chúng tôi không nhận được khoản thanh toán của bạn trong 10 ngày tới, chúng tôi sẽ công khai mã của bạn hoặc sử dụng chúng theo cách khác.

Tôi sợ rằng bạn an toàn khi giả định họ sẽ làm điều đó cho dù bạn có trả tiền chuộc hay không . Đặc biệt là bit "sử dụng chúng khác".

3
Marc.2377