Google Dorking으로 웹사이트, 데이터베이스, IoT 장치의 정보 노출과 취약점 찾기

개요

Google은 전 세계 웹의 방대한 인덱스입니다. 고급 검색 연산자(advanced operators)를 적절히 조합하면, 평범한 검색으로는 찾기 어려운 민감한 파일, 관리자 페이지, 공개된 데이터베이스 덤프, IoT 장치의 웹 인터페이스 등을 찾아낼 수 있습니다. 보안 연구자와 악성 행위자 모두 이 기법을 사용합니다. 이 문서는 Google Dorking의 개념, 기법, 실무적 활용(합법적 범위 내), 방어 대책, 운영 절차를 정리합니다.

정의: Google Dorking — 구글의 고급 검색 연산자를 사용해 공개된(혹은 노출된) 정보·리소스를 검색하는 실무 기법.

왜 중요하고 어떤 위험이 있나

• 노출된 관리자 로그인, 구성 파일, 데이터베이스 덤프, 이메일 목록 등은 계정 탈취·서비스 침해로 이어질 수 있습니다.
• 공격자는 추가 탐색 없이 검색만으로 초기 침투점(foothold)을 찾을 수 있습니다.
• 방어자는 같은 기법으로 자산을 점검하고 노출을 줄일 수 있습니다.

중요: 인가되지 않은 시스템에 대한 검색·침투 시도는 많은 관할구역에서 불법입니다. 보안 점검은 항상 서면 허가(범위·범용성 명시)를 받아 진행하세요.

Google Dorking의 역사 요약

2002년 Johnny Long가 구글 검색 쿼리로 드러나는 민감 정보를 수집하면서 ‘Google Dorks’라는 명칭이 널리 알려졌습니다. 이후 보안 커뮤니티와 악성 커뮤니티에서 다양한 쿼리가 공유되었습니다.

기본 문법(요약)

구글의 고급 연산자 기본 구조는 다음과 같습니다.

operator:keyword

operator 뒤에 콜론(:)을 붙이고 공백 없이 키워드 또는 값이 옵니다. 이들 쿼리 문자열을 ‘도크(dork)’ 또는 ‘구글 덕(google dork)’이라고 부릅니다.

자주 쓰이는 단순 연산자(요약 표)

위 연산자들을 조합해 목적에 맞는 도크를 만듭니다. 단순 도크는 민감 문서와 노출된 페이지를 찾는 데 유용하고, 복잡 도크는 특정 취약점이나 구성 실수를 찾을 때 사용됩니다.

예제와 해설

• 관리자 로그인 페이지 예제:

inurl:admin intitle:login

설명: URL에 admin이 포함되고 페이지 타이틀에 login이 들어가는 결과를 찾습니다.

• 이메일 목록(엑셀 파일) 찾기:

intext:@gmail.com filetype:xls

설명: 본문에 @gmail.com이 포함되고 엑셀(xls) 파일로 인덱싱된 결과를 찾습니다. 공개된 이메일 목록을 찾을 때 사용됩니다.

• SQL 인젝션 흔적/덤프 찾기(예시 복구·해석용):

inurl:group_concat(username filetype:php intext:admin

설명: group_concat가 URL에 있고 PHP 파일로 인덱싱되며 본문에 admin이 포함된 결과를 검색합니다. 공격자가 남긴 흔적이나 취약한 스크립트를 찾을 때 쓰일 수 있습니다.

• 포트 포함 URL 검색(예: 8443 포트가 URL에 있는 사이트):

inurl:8443 -intext:8443

설명: URL에 8443이 포함되지만 본문 텍스트에 8443이 반복적으로 나오지 않는 항목을 찾습니다. 포트 노출된 웹관리 인터페이스를 식별할 때 유용합니다.

• 특정 사이트 내 비표준 호스트/도메인 나열:

site:example.com -site:www.example.com

설명: example.com 도메인 내에서 www 서브도메인을 제외한 결과만 필터링합니다. 서브도메인/호스트 열거에 사용됩니다.

단순 도크와 복잡 도크의 차이

• 단순 도크: 하나 또는 둘의 연산자 조합으로 민감한 문서·페이지를 찾습니다. 예: filetype:xls intext:@company.com
• 복잡 도크: 여러 연산자, 정규식 비슷한 키워드, 부정/포지티브 필터(-site, -intext 등)를 조합해 특정 취약점·구성 오류를 추적합니다. 공격자가 실제 착취에 더 가까운 결과를 얻을 때 사용합니다.

언제 실패하는가(한계와 오해)

• 비공개 네트워크·비인덱싱 자원: robots.txt, noindex, 인증 자원 등은 구글 인덱스에 없거나 제한됩니다.
• 동적 콘텐츠/API 응답: 자바스크립트로 동적으로 로드되는 자원은 인덱스에 반영되지 않을 수 있습니다.
• 적절한 키워드 부족: 잘못된 키워드 조합은 노이즈가 많거나 결과를 놓칵니다.
• 법적·윤리적 제약: 많은 기관은 공개 인덱스에 올라간 자료라도 내부 정책상 민감 자료로 간주해 처리합니다.

요약: 구글 도킹은 강력하지만 전부를 대체하지는 않습니다. 다른 기법과 병행해 사용해야 합니다.

대안 접근법(공격자·수비자 관점)

• Shodan, Censys: 직접적으로 인터넷 연결 장치를 검색하고 포트·서비스 정보를 제공.
• Passive DNS, Certificate Transparency 로그: 도메인·서브도메인 열거에 유리.
• 사이트 내부 로그 및 구성검토: 외부 인덱스가 놓친 자원 확인.
• 웹 크롤러(합법적 범위), API 기반 검색: 대규모 자동 수집을 위한 합법적 방법.

각 도구는 장단점이 있으므로 목적(자산 식별, 취약점 찾기, 포렌식)에 따라 조합 사용합니다.

보안 관점: 방어·완화 전략

• 민감 파일 접근 제한: 구성 파일, 로그 파일, 백업 파일은 웹 루트에 두지 말고 인증을 걸 것.
• robots.txt 의존 금지: robots.txt는 검색 엔진에 ‘안보여주기’ 요청일 뿐, 보안 수단이 아님.
• 인덱싱 제어: 민감 페이지에 X-Robots-Tag: noindex 헤더 또는 meta noindex 태그 적용.
• 공개된 파일 형식 점검: filetype:xls/pdf/doc 등으로 인덱스된 파일을 주기적으로 검사.
• 기본 계정·약한 비밀번호 제거: 관리자 페이지 URL을 숨기는 것만으로는 불충분.
• 모니터링·알림: 새로운 서브도메인, 인덱스 파일 변화를 감지하는 워크플로 구성.
• 보안 헤더 및 인증 강화: 웹 인터페이스는 TLS, IP 화이트리스트, 2FA 등으로 보호.

중요: 보안은 다층적 접근이 필요합니다. 인덱스 차단 하나만으로 안심하면 위험합니다.

윤리·법적 고려사항 (국가별 법 규정 확인 필수)

• 허가 없는 접근/변조는 불법입니다. 단순한 공개 검색도 기관 정책·국가법에 저촉될 수 있습니다.
• 보안 연구자는 항상 서면 동의(스코프)를 확보하고 책임 있는 공개(Responsible Disclosure)를 따르세요.
• 민감 데이터(개인식별정보, 금융정보 등)를 발견하면 즉시 해당 조직에 연락하고, 법적 고지·개인정보 보호 규정(GDPR 등)에 따라 처리합니다.

운영 절차(간단 SOP) — 합법적 자산 점검용

1. 목적과 범위 정의: 점검 대상 도메인/서브도메인과 허용 시간을 명시.
2. 서면 허가 수집: 고객·내부 승인 문서 확보.
3. 도크 목록 및 자동화 도구 준비: 사용 쿼리, 속도 제한, 결과 저장 방식 결정.
4. 비파괴 검색 실행: GET 요청 수준의 검색만 수행(취약점 익스플로잇 없음).
5. 결과 분류: 민감 노출, 비민감 문서, 오탐.
6. 즉각 차단 권고: 민감 노출 시 즉시 접근 차단 및 파일 삭제/재배치 권고.
7. 보고서 작성: 재현 단계, 영향, 우선순위, 완화책 포함.
8. 재검증: 수정 후 결과 재검증.

역할별 체크리스트

• 펜테스터

  • 서면 범위·동의서 확보
  • 자동화 쿼리 목록 준비 및 속도 제한 설정
  • 역추적 로깅 최소화(법적 고려)

• 보안 운영팀(SecOps)

  • 정기적으로 filetype/ site: 쿼리로 자산 인덱싱 확인
  • 민감 파일의 인덱싱 차단 및 알림 규칙 마련

• 개발자/운영팀

  • 백업·구성 파일을 웹 루트에 두지 않음
  • 인증·권한 검증 적용

사고 대응(Incident runbook) — 민감 문서가 검색될 때

1. 발견 기록: 스크린샷, 쿼리, 결과 URL, 인덱스 시간 캡처
2. 긴급 차단: 파일 접근 권한 변경 또는 파일 제거(비즈니스 영향 고려)
3. 영향 분석: 어떤 데이터가 노출되었는가(PII, 계정, 인증정보 등)
4. 법률·컴플라이언스 상담: 개인정보법, 규제 요구사항 확인
5. 알림: 내부 이해관계자 및 필요 시 외부 당국/사용자 통지
6. 복구/완화: 재발 방지 조치 적용
7. 포렌식 보존: 원본 증거는 법적 절차 위해 보존

자동화와 API 사용 시 주의사항

• Google 검색 결과를 대규모로 스크랩하려면 Google 정책을 확인하세요. 무단 스크래핑은 차단이나 법적 문제가 발생할 수 있습니다.
• Google Custom Search API 또는 합법적 크롤링을 통한 속도·쿼터 관리 권장.

테스트 케이스와 수용 기준(예시)

• 테스트 항목: 파일 인덱싱 탐지

  • 입력: site:example.com filetype:pdf
  • 기대 결과: 민감 문서(pdf)가 결과에 나오지 않음(모든 민감 문서가 noindex 처리 또는 접근 제한)

• 테스트 항목: 관리자 페이지 노출

  • 입력: site:example.com intitle:login inurl:admin
  • 기대 결과: 외부에서 접근 가능한 관리자 페이지 없음 또는 인증 강제

수용 기준: 모든 민감 자산이 검색 결과에 나타나지 않거나, 나타나더라도 인증·권한으로 접근이 차단되어야 통과.

용어집(한 줄)

• 도크(Dork): 고급 구글 검색 연산자 조합을 말함.
• 인덱스(Index): 검색 엔진이 수집해 저장한 웹 문서의 집합.
• noindex: 검색 결과에 해당 페이지를 제외하도록 지시하는 설정.

정신 모델과 휴리스틱

• ‘노출 ≠ 의도적 공개‘라는 전제를 유지하세요. 많은 민감 데이터 노출은 실수(잘못된 설정, 백업 업로드)를 통해 발생합니다.
• ‘열린 금고 검사’로 생각하세요. 구글은 당신의 금고를 열쇠 없이 보여줄 수 있는 창고입니다. 창고를 닫아야 합니다.

실제 예시 쿼리 요약(안전한 검토용)

• 공개 이메일 스프레드시트: intext:@company.com filetype:xls
• 공개 구성 파일: inurl:”/config” filetype:env
• 백업 파일: filetype:sql site:example.com

중요: 위 쿼리로 타사 시스템을 무단 검사하지 마세요. 합법적 범위 내에서만 사용하세요.

개인정보·GDPR 관련 메모

• EU 개인정보(PII) 노출을 발견하면 즉시 내부 법무팀과 협의하고, GDPR의 보고 의무(72시간 내 신고 등)를 검토하세요.
• 발견된 PII를 보관하거나 공유할 때는 최소화 원칙과 암호화를 준수하세요.

비교: Google Dorking vs. 전문 검색엔진

• Google: 웹 인덱스 범위가 넓고 문서·파일 중심. 검색 연산자가 풍부.
• Shodan/Censys: 인터넷에 연결된 장치·포트 중심. 서비스·서버 검색에 강점.

둘을 함께 사용하면 자산 식별 범위가 넓어집니다.

사고 예시: 노출된 DB 덤프 발견 시 권장 절차

1. 노출 스냅샷 저장(읽기 전용, 증거 수집 목적)
2. 조직에 즉시 보고 및 접근 차단 요청
3. 영향 범위 식별(계정·비밀번호·PII 포함 여부)
4. 패스워드 재설정 권고, 인증토큰 폐기
5. 로그·포렌식 수집 및 외부 신고(법적 필요 시)

추가 자료 및 도구(참고용, 합법적 사용 전제)

• Google Custom Search API(공식 문서 참조)
• Shodan, Censys: 장치·서비스 검색
• 도메인·인증서 로그 모니터링(CT 로그)

요약과 권장 행동

• Google Dorking은 강력한 자산 식별 도구입니다. 합법적·윤리적 범위에서 보안 점검과 방어용으로만 사용하세요.
• 주기적으로 인덱스 검사, 민감 문서 제거, 인증 강화, 모니터링 규칙을 적용하세요.
• 무단 조사·익스플로잇은 법적 책임으로 이어질 수 있습니다. 항상 서면 동의와 책임 있는 공개 절차를 따르세요.

소셜 미리보기(제안):

• 제목: Google Dorking으로 찾아내는 노출 자산과 방어 실무
• 설명: 구글 고급 검색으로 노출된 민감 정보를 발견하고, 합법적으로 점검·완화하는 방법을 요약합니다.

공식 발표문(100-200단어): Google Dorking은 구글의 고급 검색 연산자를 이용해 공개된 민감한 파일과 노출된 웹 리소스를 찾아내는 기법입니다. 이 문서는 기본 문법과 실무 예제, 윤리·법적 고려사항, 방어 전략, 운영 SOP와 사고 대응 절차를 제공합니다. 보안 연구자와 운영팀은 글에서 제시한 체크리스트와 테스트 케이스를 활용해 자산 인덱싱을 정기적으로 점검하고, 민감 데이터의 공개 노출을 차단하십시오. 모든 활동은 반드시 서면 허가를 받은 범위 내에서 수행해야 합니다.