Đối với những người săn tiền thưởng lỗi, kho lưu trữ GitHub có thể tiết lộ nhiều thông tin hữu ích. Có thể có vấn đề với các mục tiêu không phải lúc nào cũng là nguồn mở. Đôi khi thông tin có thể được sử dụng để chống lại công ty mục tiêu bị tiết lộ nhầm bởi các thành viên của tổ chức và các sáng kiến ​​nguồn mở của họ. Tôi sẽ cung cấp cho bạn tổng quan nhanh trong bài viết này để giúp bạn bắt đầu quét các kho lưu trữ GitHub để tìm các lỗ hổng và thực hiện trinh sát chung.

1-Nhân bản hàng loạt

Bạn chỉ có thể tiến hành nghiên cứu của mình trên github.com, tuy nhiên, để kích hoạt thử nghiệm cục bộ, tôi khuyên bạn nên sao chép mọi kho lưu trữ mục tiêu. GitHubCloner của @mazen160 là một sản phẩm tuyệt vời . Tất cả những gì bạn phải làm là thực thi tập lệnh để sẵn sàng hoạt động.

$ python githubcloner.py --org organization -o /tmp/output

      
                

                    
                    
                
            

Điều quan trọng là phải thực sự hiểu dự án mà bạn đang hướng tới trước khi bắt đầu phân tích tĩnh. Sử dụng các tính năng chính trong khi chạy dự án. Lý do tôi gọi đây là “bước Jobert” là vì tôi nghe nói rằng trước khi bắt đầu mỗi cuộc săn lùng, Jobert sử dụng dự án và hiểu rõ về mục tiêu trước khi tìm kiếm điểm yếu.

3- Phân tích thủ công

Câu nói “học làm nên làm ra” áp dụng trong trường hợp này. Nếu bạn có thể học một ngôn ngữ lập trình, bạn sẽ có thể hiểu được nội dung cơ bản của các biện pháp phòng ngừa bảo mật cần thực hiện và tránh.

Bạn có thể bắt đầu tìm kiếm khi bạn đã quen thuộc với mục tiêu và kiến ​​trúc của nó. Tìm kiếm các từ khóa mà bạn quan tâm, quen thuộc hoặc bạn biết rằng các nhà phát triển thường mắc sai lầm.

Dưới đây là danh sách cơ bản của một số cụm từ tìm kiếm mà tôi sẽ sử dụng trong lần đánh giá rộng đầu tiên:

• API và khóa. (Nhận thêm một số điểm cuối và tìm khóa API.)
• mã thông báo
• bí mật
• LÀM
• mật khẩu
• dễ bị tổn thương
• http:// & https://

• CSRF
• ngẫu nhiên
• băm
• MD5, SHA-1, SHA-2, v.v.
• HMAC

Một bước quan trọng khác là xem lại lịch sử cam kết. Bạn sẽ ngạc nhiên về lượng thông tin bạn có thể thu thập được từ các cam kết. Tôi đã thấy những người đóng góp lầm tưởng rằng họ đã xóa thông tin đăng nhập trong khi họ vẫn ở trong lịch sử cam kết. Nhờ lịch sử git, tôi đã phát hiện ra các điểm cuối cũ vẫn hoạt động. Ngoài những mối quan tâm hiện tại, bạn có thể gặp phải các vấn đề lịch sử có thể tránh được do các cam kết cũ.

4- Dụng cụ

Đôi khi việc tự động hóa các nhiệm vụ nhàm chán có thể giúp cung cấp cho bạn cái nhìn tổng quan cơ bản về những gì cần tìm. Điều quan trọng cần nhớ là bạn không bao giờ nên sao chép và dán kết quả quét vào báo cáo. Bạn sẽ nhận được rất nhiều thông tin sai lệch, vì vậy bạn phải luôn điều tra cẩn thận mọi vấn đề tiềm ẩn để đảm bảo rằng chúng có thể bị khai thác.

Công cụ chính mà tôi sử dụng khi theo đuổi các dự án Python là Bandit .

Kẻ cướp sẽ xác định các sự cố phổ biến nhưng thường trả về kết quả dương tính giả hoặc kết quả treo thấp. Vì vậy, sử dụng nó một cách thận trọng. Không nghi ngờ gì nữa, nó không nên được dựa vào.

$ bandit -r path/to/your/code -ll

Snyk.io là một công cụ tuyệt vời để kiểm tra các phụ thuộc. Nền tảng hỗ trợ nhiều loại ngôn ngữ.

Để trinh sát, nhiều nhà nghiên cứu đề xuất sử dụng Gitrob . Công cụ này sẽ tìm kiếm thông tin nhạy cảm trong kho GitHub công khai.

$ gitrob analyze acme,johndoe,janedoe

$ truffleHog https://github.com/dxa4481/truffleHog.git

Đối với các ứng dụng Ruby on Rails, tôi khuyên dùng Brakeman . Brakeman là một trình quét bảo mật phân tích tĩnh có thể tìm thấy rất nhiều vấn đề bảo mật khác nhau trong mã.

Sử dụng LinkFinder của Gerben Javado để tìm điểm cuối trong tệp JS của kho lưu trữ.

$ python linkfinder.py -i 'path/to/your/code/*.js' -r ^/api/ -o cli

OK, nghiêm túc không xây dựng xã hội các chủ sở hữu dự án.

Báo cáo kết quả của bạn

Như mọi khi, khi nói đến săn tiền thưởng lỗi, hãy đọc kỹ chính sách của chương trình. Rất hiếm khi một chương trình chấp nhận báo cáo thông qua GitHub. Liên hệ với nhóm bảo mật hoặc nếu có thể, hãy sử dụng nền tảng tiền thưởng lỗi như HackerOne hoặc Bugcrowd

Bên cạnh đó, một điều thú vị về thử nghiệm hộp trắng là vì bạn có quyền truy cập vào mã nên việc đề xuất cách khắc phục hoặc gửi bản vá có thể dễ dàng hơn.

CẢM ƠN VÌ ĐÃ ĐỌC NÀY!