Các công cụ tìm kiếm được xây dựng để lập chỉ mục nội dung. Tuy nhiên, kẻ tấn công lại sử dụng chúng để lập chỉ mục những lỗi sai của bạn. Truy vấn allintext:login loại tập tin:log Thoạt nhìn có vẻ vô hại. Trên thực tế, đây là một trong những cách đơn giản nhất để phát hiện các tập tin nhật ký bị lộ chứa luồng xác thực, thông tin đăng nhập, mã thông báo và dữ liệu cơ sở hạ tầng nội bộ.
Nếu Google có thể xem được các nhật ký đó, thì kẻ tấn công cũng có thể. Một khi thông tin được lập chỉ mục, việc bị lộ là điều không thể tránh khỏi. Hơn nữa, khi thông tin đăng nhập xuất hiện trong một tệp có thể truy cập công khai, thì vụ xâm phạm đã bắt đầu rồi.
1. Tại sao lại sử dụng allintext:login filetype:log Nguy hiểm hơn vẻ ngoài của nó
Google dork là một truy vấn tìm kiếm sử dụng các toán tử nâng cao để xác định vị trí nội dung nhạy cảm hoặc bị cấu hình sai mà các công cụ tìm kiếm đã lập chỉ mục. Nó không khai thác Google, mà thay vào đó, nó khai thác điểm yếu của bạn.
Truy vấn này kết hợp hai toán tử:
- allintext: Trả về các trang mà tất cả các thuật ngữ đều xuất hiện trong nội dung văn bản.
- loại tập tin:log giới hạn kết quả trong
.logcác tập tin
Vì thế:
Có nghĩa: "Hãy cho tôi xem các tệp nhật ký có chứa từ này. login".
Thoạt nhìn, điều đó có vẻ tầm thường. Tuy nhiên, trên thực tế, nó thường quay trở lại:
- Nhật ký máy chủ web bị lộ công khai
- CI/CD nhật ký được tải lên dưới dạng hiện vật
- Nhật ký gỡ lỗi vô tình committed đến kho lưu trữ
- Nhật ký ứng dụng chứa thông tin đăng nhập dạng văn bản thuần.
Đây không phải là lỗi của công cụ tìm kiếm. Thay vào đó, nó là một lỗ hổng bảo mật dữ liệu Nguyên nhân là do cấu hình sai. Google chỉ đơn giản là lập chỉ mục những nội dung có thể truy cập công khai.
2. Kẻ tấn công thực sự tìm thấy gì trong các tệp nhật ký bị lộ
Khi kẻ tấn công chạy allintext:login loại tập tin:logHọ không duyệt web một cách ngẫu nhiên. Họ đang tìm kiếm dấu vết xác thực.
2.1 Thông tin xác thực dạng văn bản thuần túy
Nhật ký thường chứa các mục như sau:
or
Hoặc thậm chí là thông tin đăng nhập SMTP:
Việc ghi nhật ký các thông tin xác thực là một trong những cách nhanh nhất để làm rò rỉ thông tin đăng nhập trong môi trường sản xuất. Do đó, chỉ cần một tệp nhật ký bị lộ cũng có thể làm vô hiệu hóa toàn bộ mô hình kiểm soát truy cập của bạn.
2.2 Mã thông báo phiên và JWT
Ngay cả khi mật khẩu không được lưu lại, mã thông báo thường vẫn được ghi.
Ví dụ:
Một JWT hợp lệ hoặc cookie phiên bên trong .log Tệp này có thể cho phép:
- Chiếm quyền điều khiển phiên
- Leo thang đặc quyền
- Di chuyển ngang qua các hệ thống nội bộ
Nói cách khác, các mã thông báo trong nhật ký biến đầu ra gỡ lỗi thành một phương thức vượt qua xác thực.
2.3 CI/CD Hiện vật
Nhật ký quá trình xây dựng đặc biệt nguy hiểm. Trên thực tế, CI/CD Các hệ thống thường in các biến môi trường trong các bước biên dịch.
Kẻ tấn công thường phát hiện ra:
Chứa các dòng như sau:
If CI/CD Các hiện vật được công khai, vậy thì bí mật cũng được công khai. Công cụ tìm kiếm Google (Google dork) chỉ đơn giản là đẩy nhanh quá trình khám phá.
2.4 Dữ liệu đám mây và cơ sở hạ tầng
Các nhật ký bị lộ thường tiết lộ:
- Khóa truy cập AWS
- chuỗi kết nối lưu trữ Azure
- URL dịch vụ nội bộ
- Thông tin xác thực cơ sở dữ liệu
- Điểm cuối Redis
Ngay cả khi thông tin đăng nhập được thay đổi sau đó, kẻ tấn công vẫn nắm giữ:
- Bản đồ cơ sở hạ tầng
- Quy ước đặt tên
- Thu thập thông tin tình báo mục tiêu cho các cuộc tấn công trong tương lai
Do đó, các nhật ký bị lộ cung cấp cả khả năng truy cập và thu thập thông tin tình báo.
3. Lý do những nhật ký này được công khai ngay từ đầu
Nhật ký hệ thống không tự nhiên xuất hiện trên Google. Chúng được lập chỉ mục vì chúng có thể truy cập công khai.
3.1 Máy chủ web cấu hình sai
Các kiểu mẫu phổ biến bao gồm:
/logs/các thư mục có thể truy cập mà không cần xác thực- Đã bật hiển thị danh sách thư mục
- Nginx hoặc Apache phục vụ dữ liệu thô.
.logcác tập tin
Nếu có thể truy cập nhật ký hệ thống qua HTTP, thì nhật ký đó có thể được lập chỉ mục.
3.2 CI/CD Tiếp xúc với hiện vật
Những sai lầm điển hình:
- Các hiện vật công khai được kích hoạt trong Tác vụ GitHub
- Nhật ký đã được tải lên các nhóm lưu trữ S3 đang mở.
- Pipeline Dấu vết có thể truy cập mà không cần xác thực.
A pipeline Việc lưu trữ nhật ký trong một bucket công khai đồng nghĩa với việc công khai những bí mật của nó.
3.3 Chế độ gỡ lỗi trong môi trường sản xuất
Các thiết lập mặc định của framework có thể nguy hiểm:
Ngoài ra, việc ghi nhật ký yêu cầu quá mức có thể dẫn đến việc in ra:
- Headers
- Tokens
- Toàn bộ nội dung yêu cầu
Việc ghi nhật ký gỡ lỗi trong môi trường sản xuất biến ứng dụng của bạn thành một công cụ xuất thông tin xác thực.
3.4 Nhật ký Docker & Container
Môi trường container hóa tạo ra các con đường tiếp xúc mới:
- Nhật ký được gắn vào các ổ đĩa dùng chung.
- Các sidecar xuất nhật ký đến các điểm cuối không được bảo mật.
- Khúc gỗ dashboardcó quyền truy cập công cộng
Nếu nhật ký container được hiển thị qua HTTP hoặc bộ nhớ mở, chúng có thể tìm kiếm được. Cuối cùng, chúng sẽ được lập chỉ mục.
4. Luồng tấn công thực tế: Từ kẻ ngốc đến kẻ đột phá
Một chuỗi tấn công điển hình trông như thế này:
Kẻ tấn công thực hiện:
- Những phát hiện được hé lộ
.loghồ sơ - Trích xuất:
- Mã thông báo JWT
- Tiêu đề xác thực cơ bản
- Chuỗi kết nối cơ sở dữ liệu
Thử xác thực với:
- Điểm cuối API
- Bảng quản trị
- Dịch vụ nội bộ
Nếu quá trình xác thực thành công, kẻ tấn công có thể:
- Nâng cao đặc quyền
- Di chuyển ngang
- Truy Cập CI/CD
- Làm tổn hại chuỗi cung ứng
Điều bắt đầu như một truy vấn tìm kiếm đã trở thành:
- Chiếm quyền điều khiển phiên
- Tấn công nhồi nhét thông tin đăng nhập nội bộ
- Pipeline tiếp quản
- Nhiễm độc cổ vật
Tất cả đều được lấy từ một tệp nhật ký được lập chỉ mục công khai.
5. Tại sao việc ghi nhật ký "quá nhiều" lại là một vấn đề về bảo mật ứng dụng
Việc khai thác gỗ không phải là trung lập. Thay vào đó, nó tạo ra... kho dữ liệu thứ cấp.
Nếu bạn ghi lại dữ liệu nhạy cảm, về cơ bản bạn đang tạo ra một bản sao thứ hai của những bí mật của mình.
Tuy nhiên, nhật ký hệ thống thường bị loại trừ khỏi quá trình mô hình hóa mối đe dọa. Theo STRIDE, điều này thể hiện rõ ràng ở các điểm sau:
Công bố thông tin
Do đó, hãy đảm bảo an toàn. SDLC Các cơ sở thực hành nên coi nhật ký như sau:
- Các hiện vật liên quan đến an ninh
- Tài sản nhạy cảm
- Các thành phần cơ sở hạ tầng cần được bảo vệ
Nếu mô hình phân tích mối đe dọa của bạn bỏ qua nhật ký, thì nó chưa hoàn chỉnh.
6. Cách ngăn chặn rò rỉ thông tin đăng nhập trong các tệp nhật ký
6.1 Ngừng ghi nhật ký bí mật
Không bao giờ đăng nhập:
- Mật khẩu
- Tokens
- Khóa API
- ID phiên
- Tiêu đề ủy quyền
Ngay cả ở chế độ gỡ lỗi.
Khi có thể, hãy triển khai tính năng tự động che mờ thông tin.
6.2 Khai thác gỗ có cấu trúc và an toàn
Sử dụng tính năng ghi nhật ký có cấu trúc với che giấu và lọc thông tin.
Ví dụ (Node.js):
Ví dụ (Python):
Nguyên tắc cốt lõi rất đơn giản: bí mật không bao giờ được phép lọt vào nhật ký hệ thống.
6.3 Lưu trữ nhật ký khóa
Các biện pháp kiểm soát an ninh cần bao gồm:
- Tắt tính năng liệt kê thư mục
- Bảo vệ
/logs/các đường dẫn có xác thực - Hạn chế quyền truy cập vào nhóm
- Áp dụng chính sách lưu giữ hồ sơ
- Mã hóa nhật ký khi lưu trữ
Nhật ký hệ thống không bao giờ được phép truy cập công khai qua giao thức HTTP.
6.4 CI/CD Guardrails
Việc rà soát thủ công là không đủ. Thay vào đó, hãy triển khai các biện pháp kiểm soát tự động:
- Quét bí mật nhật ký trước khi công bố hiện vật.
- Quá trình biên dịch sẽ thất bại nếu phát hiện thấy mã thông báo.
- Ngăn chặn việc tải lên các tệp tin chứa thông tin xác thực.
- Xác thực mã băm cho các tạo phẩm
CI/CD Nên chặn việc tiếp xúc trước khi quá trình lập chỉ mục diễn ra.
7. Xygeni ngăn chặn allintext như thế nào:login Loại tệp: nhật ký sự cố
Vấn đề không nằm ở từ khóa tìm kiếm của Google. Vấn đề là mức độ hiển thị. Do đó, cần phải phòng ngừa trước khi lập chỉ mục.
7.1 Phát hiện thông tin bí mật trong nhật ký và hiện vật
Quét Xygeni:
- Nhật ký ứng dụng
- CI/CD dấu vết công việc
- Xây dựng các hiện vật
- Các lớp Docker
- Đầu ra tuần tự
Nếu thông tin xác thực, mã thông báo hoặc các giá trị nhạy cảm xuất hiện trong .log Xygeni sẽ gắn cờ các tệp đó ngay lập tức.
7.2 CI/CD Guardrails Chặn sự tiếp xúc đó
Thay vì dựa vào việc xem xét thủ công, Xygeni tăng cường an ninh tại... pipeline cấp độ:
Điều này:
- Quá trình xây dựng thất bại khi các thông tin bí mật xuất hiện trong nhật ký.
- Ấn phẩm hiện vật Blocks
- Ngăn ngừa việc vô tình bị lộ thông tin cá nhân trước công chúng.
- Ngăn chặn các thao tác hợp nhất không an toàn trước khi đến nhánh chính.
Nếu một tác vụ CI in ra một mã thông báo, thì pipeline thất bại
Không có chỉ mục.
Không tiếp xúc.
Không có sự cố nào xảy ra.
7.3 Bảo vệ bằng phương pháp Shift-Left trước khi Google phát hiện ra
Thời gian rất quan trọng.
Thay vì phản ứng lại:
Xygeni giải quyết vấn đề này:
- At commit thời gian
- Trong khi pull request xác nhận
- Trong khi pipeline thực hiện
- Trước khi công bố hiện vật
Nếu nhật ký hệ thống không bao giờ được công khai, Google sẽ không bao giờ lập chỉ mục cho nó.
Tóm lại: Nếu Google có thể lập chỉ mục, thì kẻ tấn công đã làm điều đó rồi.
Các tập tin nhật ký không phải là vô hại. Trên thực tế, chúng hiếm khi chỉ là tạm thời. Theo mặc định, chúng không được bảo mật. Do đó, mỗi tập tin nhật ký nên được coi là một tài sản có liên quan đến bảo mật, chứ không chỉ là đầu ra gỡ lỗi.
Nếu dữ liệu nhạy cảm bị rò rỉ .log tập tin và trở nên có thể truy cập công khai. Nó lập tức trở thành một điểm yếu dễ bị tấn công. Hơn nữa, một khi đã được công cụ tìm kiếm lập chỉ mục, mức độ hiển thị sẽ vượt ngoài tầm kiểm soát của bạn.
Giải pháp không phải là ngừng ghi nhật ký. Thay vào đó, cần phải ghi nhật ký một cách có trách nhiệm và thực thi các biện pháp kiểm soát chặt chẽ đối với việc lưu trữ và phân phối. Nói cách khác, bảo mật phải mở rộng ra ngoài phạm vi ứng dụng và vào lớp quan sát.
Thay thế:
- Ngừng lưu trữ thông tin bí mật
- Khóa lưu trữ nhật ký
- Thi hành pipeline guardrails
- Tự động hóa việc phát hiện và thực thi chính sách.
Cuối cùng, Phòng ngừa phụ thuộc vào thời điểm. Bởi vì một khi đã... allintext:login loại tập tin:log Trả về tên miền của bạn, sự cố đã bắt đầu.
