CHO NAM GI

개인 공부 블로그입니다.

visitor

4 분 소요

개요

4차 멘토링의 핵심은 단순한 취약점 도출을 넘어, 실무 수준의 보고서 작성 능력과 직관적인 전달력을 개선하는 것이었다. 기술적 구현보다 “누구나 이해할 수 있는 형태로 문서를 정리하는 능력”이 실무에서 더 중요하다는 점을 다시 확인했다.

1. 문서 작성 원칙

보는 사람 중심으로 작성하기

보고서는 작성자 본인이 편한 형태가 아니라, 보는 사람(담당자, 이행 점검 수행자)이 이해하기 편한 형태로 작성해야 한다.

용어 통일 및 문체 정제

  • ‘애플리케이션’을 ‘웹 애플리케이션’으로 통일하는 등 문서 전반의 용어를 일관성 있게 맞춰야 한다.
  • 서술어 시제, 능동태/수동태도 통일한다.
  • 공공기관 및 은행권 기준을 고려하여 불필요한 외국어 사용을 배제하고 한글 명칭으로 통일하는 것이 좋다.
  • ~됨, ~되었다 등 수동태 표현을 지양하고 능동태로 변경한다.
  • AI 말투와 불필요한 문장을 제거하여 간결하게 작성한다.

출처와 캡션

  • 보고서의 회사 로고를 수정한다.
  • 작성된 기준이나 데이터에 대해서는 반드시 출처를 기재한다.
  • 캡션은 그림과 표에만 적용하여 깔끔하게 구성한다.

수행계획서와 결과 보고서 동기화

수행계획서(일정, 담당자 정의 문서)와 결과 보고서는 하나의 세트로 구성되어야 한다.

2. 웹 취약점 진단 보고서 수정사항

점검 기준 및 출처 명시

  • 점검 기준표(항목명, 중요도, 출처 등)를 보고서 초반부에 배치한다.
  • 어떤 자료를 참고하여 기준을 수립했는지(예: 주통기) 명시한다.
  • 엑셀 등을 별도로 사용한다면 ‘별첨 참고’ 형식으로 연결한다.

금지 활동 항목 삭제

1.4 금지 활동(DoS, 플러딩 등) 항목은 모의해킹이나 침투 테스트(레드티밍)용이므로 취약점 진단 보고서에서는 불필요하다. 전체 삭제한다.

중요도와 영향도의 구분

  • 항목 자체에 대한 ‘중요도’와 수행 결과에 대한 ‘영향도’를 혼동하지 않아야 한다.
  • ‘중요도 항목 기준’은 항목에 대한 중요도를 의미하는 것이지, 수행 결과에 대한 영향도가 아니다.

중요도 평가 기준 재검토

주통기 기준 웹 취약점은 모두 중요도가 ‘상’이므로, 상/중/하를 따지기보다는 ‘상’ 항목 중심으로 통일한다.

XXE가 SSRF보다 공격 범위(OS 명령어 실행 동급)가 더 넓음에도 불구하고, 현재 보고서에서는 SSRF가 상, XXE가 중으로 기재되어 있다. 이 부분을 수정해야 한다.

공격 가능성을 기준에 넣지 않기

공격 가능성에 대한 멘토 설명:

  • 퍼블릭 도메인(sk.com): 외부에 공개되어 있으므로 공격 가능성이 높다.
  • 프라이빗 도메인(sk.dev.com): 내부 테스트 DB나 개발 서버 등이므로 VPN 등 별도 수단 없이는 접근이 불가능하고, 공격 가능성이 낮다.

하지만 진단 수행 전에는 대상이 퍼블릭인지 프라이빗인지 알 수 없다. 따라서 기준 수립 단계에서 ‘공격 가능성’이나 인증 여부를 평가 기준에 넣는 것은 부적절하다.

결론: 중요도 항목 전체를 재검토하고 수정한다.

진단 결과 및 취약점 상세 작성법

  • 인프라와 달리 단일 웹 대상(22개 항목)이므로, 진단 결과 요약은 복잡한 수치화 대신 단순 개수로 간결히 작성한다.
  • ‘진단 대상 항목’을 ‘취약점 위치’로 변경하고, 메뉴와 URL을 함께 작성한다.
  • 취약점 상세 설명에 공격 구문을 이미지 대신 텍스트로 추가한다. (필수는 아니며 진단 내용 상세 안에 포함되어도 무방)

대응방안

  • 4.3.1 항목의 경우 버전 업데이트로 해결 가능한지(예: SSTI 대응 1순위) 확인하고, 필요시 별첨 가이드로 연결한다.
  • 4.3.2 항목에서 클라우드 관리 로그에 기록되도록 구성한다.

3. 모의해킹 시나리오 (PPT / 시연 영상) 피드백

흐름도 통일

  • 모든 시나리오 흐름도(1, 2번)를 3번 기준인 공격자 상단 구조로 통일한다.
  • WAS 화살표 표현을 삭제한다.

시연 영상 화면 구성

  • 터미널 2개를 사용할 때 VPN 연결 여부나 현재 위치가 어디인지 명확히 구분되도록 표시한다.
  • 터미널에서 개행이 안 되는 부분은 ps 명령어 등을 활용해 보기 좋게 개선한다.

핵심 정보 하이라이트 및 속도 조절

  • 영상 속도를 전체적으로 낮춘다.
  • 크리덴셜(비밀번호 등) 확보 시 빨간 박스나 하이라이트로 명확히 보여준다.

개인정보 마스킹

PPT와 시연 영상에 포함된 개인정보와 크리덴셜은 반드시 마스킹 처리해야 한다. (주민번호 해시화 활용 가능)

명령어 시연 현실화

  • grep으로 바로 찾는 대신 실제 탐색 과정(예: KeePass backup.sh 확인)을 보여준다.
  • use database 없이 show database가 실행되는 오류를 수정한다.

4. 시나리오별 보완사항

모바일 시나리오 (시나리오 1 & 2)

  • 피싱 흐름을 빼고 ‘APK → JS Bridge 웹뷰’ 구조로 흐름을 명확히 수정한다.
  • 악성 앱 제작 및 페이지 구성에 사용된 기술과 AI 활용 내용을 명시하고, 실제 핸드폰 기종 정보를 추가하여 현실감을 높인다.
  • 해시 크래킹 설명 시 ‘자체 제작 도구’를 사용했음을 강조한다.
  • 우회를 위해 7z로 압축하여 배포한 뒤, 사용자가 압축을 해제하는 팝업 과정을 포함한다.
  • 시나리오 개요는 다이어그램 순서에 맞춰 간결하게 재작성하고, DB 탈취와 관리자 계정 탈취 문단을 명확히 분리한다.

클라우드/인프라 (시나리오 3)

  • SQLi 항목을 Prompt Injection으로 수정한다.
  • SSM(Systems Manager)이 배스천(Bastion) 서버 관리를 위해 과도한 권한이 부여되었다는 배경 설명을 첨언하여 심사위원의 이해를 돕는다.
  • 비밀번호(sk2812!@)는 Rockyou 리스트 기준 등 좀 더 규칙성 있고 어려운 형태의 값으로 수정하고 출처를 명시한다.
  • 랜섬웨어 시연 영상과 보고서 내용의 간극을 좁힌다.
  • 클라우드 관리 로그에 기록되도록 구성한다.

5. 실무 팁

AWS IAM Policy Simulator

실무에서는 get-caller-identity 명령어 사용 시 탐지될 위험이 높다. 대신 AWS IAM Policy Simulator를 활용하면 특정 IAM 권한으로 요청이 허용되는지 여부를 사전에 조용히 테스트할 수 있다. IAM 토큰 기반 인증 시 권한을 과도하게 부여하면 보안이 약해지므로 유의해야 한다.

Snagit (화면 캡처 도구)

긴 스크린샷이나 터미널 화면 캡처 시, 시작과 끝부분만 깔끔하게 잘라 편집할 수 있는 도구다. 보고서 이미지 퀄리티를 높이는 데 유용하다.

쉘 업그레이드

  • 파이썬이 없는 환경을 대비해 bash부터 시도하는 등 우선순위를 정한다.
  • 고급 쉘 활용을 위해 nc -nlvp 대신 rlwrap 사용법을 숙지한다.

아티팩트(흔적) 기록

웹 쉘을 올린 후 WAS가 이중화되어 다른 서버에 흔적이 남는 경우 등을 대비하여, 이행 점검 수행자가 파악하고 삭제할 수 있도록 아티팩트 항목을 보고서에 명시하는 것이 좋다. 멘토님이 이 부분은 아주 좋은 작성법이라고 평가했다.

기타 참고사항

  • OVPN 파일이 없어도 취약한 서비스면 내부망 공격이 가능하다.
  • 실무에서는 HISTIGNORE 설정뿐만 아니라 아예 history 기록을 남기지 않는 환경도 많다.
  • 어려운 인프라 용어에는 모두 각주를 추가한다.

6. Action Items

웹 취약점 진단 보고서 수정

  • 점검 항목 기준 추가 (항목 수, 주통기 등 출처, 선정 기준 명시 및 필요시 별첨 연결)
  • 중요도 기준 삭제하거나 한 줄로 축약 (“상 항목 중심으로 선정” 등)
  • 취약점 표 전체 수정: ‘진단 대상 항목’을 ‘취약점 위치’로 변경하고 메뉴+URL 형태로 통일
  • 공격 구문 항목을 모든 취약점 상세 내용에 추가
  • 문서 전체 용어(애플리케이션, 권한 등) 통일

모의해킹 시나리오 PPT 수정

  • 시나리오 1, 2의 흐름도를 시나리오 3번 형식(공격자 상단 구조)으로 통일 및 WAS 화살표 제거
  • 모바일 흐름도 재구성 (피싱 → APK → JS Bridge 흐름 명확화)

시연 영상 및 시나리오 보고서 수정

  • 터미널 2개 사용 장면 구분 표시 및 영상 속도 전체적으로 감속
  • SSM(Bastion)에 대한 설명(“무엇을 할 수 있는지”) 추가
  • 단순 grep 사용 부분을 하이라이트 방식으로 변경
  • 시연용 비밀번호를 규칙성 있는 어려운 값으로 수정
  • 보고서 내 SQLi를 Prompt Injection으로 수정하고, 개요를 다이어그램 순서 기준으로 간결하게(능동태) 재작성

모바일 시나리오 및 인프라/보고서 품질 개선

  • 해시 크래킹 설명 시 “자체 제작 도구 사용” 강조
  • 누락된 내용(공지사항 팝업, 압축 해제 과정) 추가 및 악성 앱 제작 과정에 사용 기술과 AI 활용 내용 명시
  • 실제 기기 정보(핸드폰 기종) 추가
  • 어려운 인프라 용어 전체 각주 처리
  • PPT 및 영상 내 개인정보 반드시 마스킹 적용
  • Snagit 등을 활용하여 캡처 이미지 퀄리티 개선
  • 대응방안 수정 및 bash_history 관련 내용 보완

댓글 남기기