검색 엔진은 콘텐츠를 색인화하도록 설계되었습니다. 그러나 공격자들은 검색 엔진을 이용하여 사용자의 오류를 색인화합니다. 해당 쿼리는 이러한 목적으로 악용될 수 있습니다. allintext :login 파일 형식:로그 겉보기에는 무해해 보일 수 있습니다. 하지만 실제로는 인증 흐름, 자격 증명, 토큰 및 내부 인프라 데이터가 포함된 노출된 로그 파일을 찾아내는 가장 간단한 방법 중 하나입니다.
구글이 해당 로그를 볼 수 있다면 공격자도 볼 수 있습니다. 일단 색인화되면 노출은 불가피해집니다. 더욱이 자격 증명이 공개적으로 접근 가능한 파일에 나타나는 순간, 이미 침해는 진행 중인 것입니다.
1. allintext를 사용하는 이유:login 파일 형식:로그는 겉보기보다 더 위험합니다.
구글 도크는 고급 연산자를 사용하여 검색 엔진에 색인된 민감하거나 잘못 구성된 콘텐츠를 찾아내는 검색어입니다. 이는 구글 자체를 악용하는 것이 아니라, 사용자의 정보 노출 위험을 악용하는 것입니다.
이 쿼리는 두 개의 연산자를 결합한 것입니다.
- allintext : 본문 텍스트에 모든 용어가 포함된 페이지를 반환합니다.
- 파일 형식:로그 결과를 제한합니다
.log파일
따라서:
수단: "해당 단어가 포함된 로그 파일을 보여주세요. login. "
언뜻 보기에는 사소해 보입니다. 하지만 실제로는 종종 같은 문제가 발생합니다.
- 공개적으로 노출된 웹 서버 로그
- CI/CD 로그가 아티팩트로 업로드되었습니다.
- 디버그 로그가 실수로 생성됨 commit저장소에 ted
- 자격 증명이 평문으로 포함된 애플리케이션 로그
이것은 검색 엔진 버그가 아닙니다. 오히려 이것은... 데이터 노출 취약성 설정 오류로 인해 발생했습니다. 구글은 공개적으로 접근 가능한 콘텐츠만 색인화했습니다.
2. 공격자들이 노출된 로그 파일에서 실제로 발견하는 것
공격자들이 달릴 때 allintext :login 파일 형식:로그그들은 무작위로 검색하는 것이 아닙니다. 그들은 인증 흔적을 찾고 있는 것입니다.
2.1 평문 자격 증명
로그에는 다음과 같은 항목이 자주 포함됩니다.
or
또는 SMTP 자격 증명까지도 가능합니다.
인증 페이로드를 로깅하는 것은 운영 환경의 자격 증명을 유출하는 가장 빠른 방법 중 하나입니다. 따라서 단 하나의 로그 파일만 노출되어도 전체 액세스 제어 모델이 무효화될 수 있습니다.
2.2 세션 토큰 및 JWT
비밀번호가 기록되지 않더라도 토큰은 종종 기록됩니다.
예 :
If CI/CD 유물은 공개되어 있고, 따라서 비밀도 공개됩니다. 구글 도크는 단지 발견 속도를 높여줄 뿐입니다.
2.4 클라우드 및 인프라 데이터
공개된 로그에는 다음과 같은 내용이 종종 드러납니다.
- AWS 액세스 키
- Azure 스토리지 연결 문자열
- 내부 서비스 URL
- 데이터베이스 자격 증명
- 레디스 엔드포인트
자격 증명이 나중에 변경되더라도 공격자는 이제 다음을 확보하게 됩니다.
- 인프라 매핑
- 명명 규칙
- 향후 공격을 위한 표적 정보
따라서 공개된 로그는 접근과 정찰을 모두 제공합니다.
3. 이러한 로그 기록이 애초에 공개되는 경로는 무엇일까요?
로그 파일이 구글에 저절로 나타나는 것은 아닙니다. 공개적으로 접근 가능했기 때문에 색인화된 것입니다.
3.1 웹 서버 구성 오류
일반적인 패턴은 다음과 같습니다.
/logs/인증 없이 접근 가능한 디렉터리- 디렉토리 목록 기능이 활성화됨
- Nginx 또는 Apache가 원시 데이터를 제공합니다.
.log파일
로그 파일이 HTTP를 통해 접근 가능한 경우, 해당 파일은 인덱싱될 수 있습니다.
3.2 CI/CD 유물 노출
일반적인 실수:
- 공용 아티팩트가 활성화되었습니다. GitHub 액션
- 공개된 S3 버킷에 로그가 업로드되었습니다.
- Pipeline 인증 없이 접근 가능한 추적 정보
A pipeline 로그를 공개 버킷에 저장하는 것은 사실상 비밀 정보를 공개하는 것과 같습니다.
3.3 프로덕션 환경에서의 디버그 모드
프레임워크 기본 설정은 위험할 수 있습니다.
또한, 과도한 요청 로깅으로 인해 다음과 같은 내용이 출력될 수 있습니다.
- 헤더
- 토큰
- 전체 요청체
프로덕션 환경에서 디버그 로깅을 사용하면 애플리케이션이 자격 증명 내보내기 도구로 변모합니다.
3.4 도커 및 컨테이너 로그
컨테이너화된 환경은 새로운 노출 경로를 제공합니다:
- 공유 볼륨에 마운트된 로그
- 보안되지 않은 엔드포인트로 로그를 내보내는 사이드카
- 로그 dashboard공공 접근이 가능한 s
컨테이너 로그가 HTTP 또는 오픈 스토리지를 통해 노출되면 검색이 가능합니다. 결국에는 인덱싱되기도 합니다.
4. 현실적인 공격 흐름: 초보자부터 공격 개시까지
일반적인 공격 과정은 다음과 같습니다.
공격자가 실행한 내용:
- 발견된 내용
.log파일 - 추출물 :
- JWT 토큰
- 기본 인증 헤더
- 데이터베이스 연결 문자열
다음 대상에 대한 인증을 시도합니다:
- API 엔드 포인트
- 관리자 패널
- 내부 서비스
인증에 성공하면 공격자는 다음과 같은 작업을 수행할 수 있습니다.
- 에스컬레이션 권한
- 옆으로 이동
- 오시는 길 CI/CD
- 공급망을 손상시키다
검색 쿼리로 시작된 것이 다음과 같이 됩니다.
- 세션 도용
- 내부 자격 증명 도용
- Pipeline 인계
- 유물 중독
모두 공개적으로 색인화된 로그 파일에서 가져온 것입니다.
5. "과도한" 로깅이 애플리케이션 보안 문제인 이유
벌목은 중립적이지 않습니다. 오히려 그것은 문제를 야기합니다. 보조 데이터 저장소.
민감한 데이터를 기록하면 사실상 비밀 정보의 복사본을 하나 더 만드는 것과 같습니다.
하지만 로그는 위협 모델링에서 제외되는 경우가 많습니다. STRIDE에서는 이것이 다음과 같이 명확하게 나타납니다.
공개 정보
그러므로, 안전합니다 SDLC 실무에서는 로그를 다음과 같이 처리해야 합니다.
- 보안 관련 아티팩트
- 민감한 자산
- 보호가 필요한 인프라 구성 요소
위협 모델이 로그를 무시한다면, 그 모델은 불완전한 것입니다.
6. 로그 파일에서 자격 증명 유출을 방지하는 방법
6.1 비밀 로깅 중지
로그를 남기지 마세요:
- 암호
- 토큰
- API 키
- 세션 ID
- 인증 헤더
디버그 모드에서도 마찬가지입니다.
가능한 한 자동 정보 삭제 기능을 구현하십시오.
6.2 체계적이고 안전한 벌목
마스킹 및 필터링 기능을 갖춘 구조화된 로깅을 사용하십시오.
예시 (Node.js):
예시(Python):
핵심 원칙은 간단합니다. 비밀은 절대로 로그 싱크에 도달해서는 안 됩니다.
6.3 통나무 보관 잠금
보안 제어에는 다음 사항이 포함되어야 합니다.
- 디렉토리 목록 표시를 비활성화합니다.
- 보호
/logs/인증이 필요한 경로 - 버킷 접근 제한
- 보존 정책을 적용합니다.
- 저장된 로그를 암호화합니다.
로그 파일은 HTTP를 통해 공개적으로 접근할 수 있어서는 안 됩니다.
6.4 CI/CD Guardrails
수동 검토만으로는 충분하지 않습니다. 자동화된 관리 시스템을 구현하십시오.
- 아티팩트 게시 전 로그에 대한 비밀 스캔
- 토큰이 감지되면 빌드를 실패시킵니다.
- 자격 증명이 포함된 아티팩트 업로드를 방지합니다.
- 아티팩트에 대한 해시 유효성 검사
CI/CD 인덱싱이 발생하기 전에 노출을 차단해야 합니다.
7. Xygeni가 allintext를 방지하는 방법:login 파일 형식: 로그 사건
문제는 구글 도크가 아닙니다. 문제는 노출입니다. 따라서 색인 생성 전에 예방 조치가 이루어져야 합니다.
7.1 로그 및 아티팩트에서의 비밀 정보 탐지
Xygeni 스캔:
- 응용 프로그램 로그
- CI/CD 직업 추적
- 빌드 아티팩트
- 도커 레이어
- 직렬화된 출력
자격 증명, 토큰 또는 민감한 값이 나타나는 경우 .log Xygeni는 파일을 감지하면 즉시 플래그를 지정합니다.
7.2 CI/CD Guardrails 해당 블록 노출
수동 검토에 의존하는 대신, Xygeni는 보안을 강화합니다. pipeline 수준 :
이:
- 로그에 비밀 정보가 나타나면 빌드가 실패합니다.
- 블록 아티팩트 게시
- 우발적인 공개 노출을 방지합니다
- 메인에 도달하기 전에 안전하지 않은 병합을 중지합니다.
CI 작업에서 토큰이 출력되면, pipeline 실패합니다.
색인 생성 안 함.
노출 없음.
아무런 사건도 없었습니다.
7.3 구글이 보기 전에 시프트 레프트 보호
타이밍이 중요합니다.
다음과 같은 상황에 반응하는 대신:
Xygeni가 문제를 해결합니다:
- At commit 시간
- 시 pull request 확인
- 시 pipeline 실행
- 유물 공개 전
로그가 공개되지 않으면 구글은 해당 로그를 색인화하지 않습니다.
결론: 구글이 색인화할 수 있다면, 공격자들은 이미 색인화했을 가능성이 높습니다.
로그 파일은 결코 무해한 것이 아닙니다. 실제로 로그 파일은 일시적인 경우가 거의 없으며, 기본적으로 비공개 정보도 아닙니다. 따라서 모든 로그 파일은 단순한 디버깅 출력물이 아니라 보안과 관련된 중요한 자산으로 간주해야 합니다.
민감한 데이터가 유출될 경우 .log 해당 파일이 공개되면 누구나 접근할 수 있게 됩니다. 그것은 즉시 공격 표면으로 변모합니다. 더욱이, 검색 엔진에 색인화되면 노출 규모는 사용자가 통제할 수 없을 정도로 커집니다.
해결책은 로깅을 중단하는 것이 아닙니다. 오히려 책임감 있게 로깅하고 저장 및 배포에 대한 엄격한 통제를 시행하는 것입니다. 다시 말해, 보안은 애플리케이션 자체를 넘어 관찰 가능 계층까지 확장되어야 합니다.
대신 :
- 비밀 정보 기록을 중지하세요
- 통나무 보관소를 잠그세요
- 적용 pipeline guardrails
- 탐지 및 정책 시행 자동화
궁극적으로, 예방은 타이밍이 중요합니다. 왜냐하면 일단 시작하면... allintext :login 파일 형식:로그 도메인을 반환하면 이미 사건이 시작됩니다.
