본격적인 버그헌팅에 앞서 가장 먼저 해야 할 일은 향상된 타겟 정보 수집이다. 향상된 타겟 정보 수집이란 말 그대로 취약점을 찾을 대상(타겟)에 대한 유의미한 데이터를 최대한 모으고 파악하는 과정을 의미한다.정보 수집을 철저히 해야 하는 가장 큰 이유는 바로 가성비 때문이다.한정된 리소스와 시간 안에서 효과적으로 취약점을 찾아내기 위해서는 타겟의 구조와 특징에 대한 광범위한 이해가 반드시 선행되어야 한다. 정보 수집의 기본, 수동 탐색이러한 정보 수집의 가장 기본이 되는 단계는 수동 탐색이다. 타겟 웹사이트에 직접 접속하여 로그인 페이지부터 각종 메뉴까지 하나하나 직접 눌러보며 전체적인 구조를 파악한다. 이 과정을 통해 사이트가 어떻게 동작하는지 관찰하고, 체크리스트를 작성하여 어떤 부분에서 공격이 가능..

"이웃의 뒷문이 열려있는 걸 우연히 알았다면 어떻게 할 것인가?"물리적인 현실 세계라면, 지나가던 선량한 이웃은 주저 없이 초인종을 누르고 "뒷문이 열려 있으니 문을 닫으라"고 알려줄 것이다. 집주인 역시 고마움을 표할 것이다. 하지만 사이버 공간에서는 이 상식이 통하지 않는다. 선의를 품고 타겟 기업의 보안 취약점을 발견하여 제보하는 행위가, 자칫 '불법 해킹'이나 '영업 방해'로 간주되어 고소장으로 되돌아오는 모순이 빈번하게 발생하기 때문이다.버그헌팅과 모의 해킹을 공부하는 수강생의 관점에서, VDP가 왜 단순한 행정 서류가 아니라 기업의 운명을 가를 수 있는 보안의 핵심 인프라인지 강의 내용을 바탕으로 깊이 있게 정리해 보았다. 1. VDP의 부재: 방치되는 선의, 커지는 보안 공백연구자들은 특정..

목표취약한 파일 업로드 기능을 악용하여 웹셸(Webshell)을 업로드.서버에서 명령어 실행을 통해 플래그 파일(/flag) 내용 획득.문제 분석파일 업로드 기능:파일 업로드 기능이 적절히 검증되지 않음.PHP 파일과 같은 실행 가능한 파일 업로드 가능.업로드된 파일 실행 가능:업로드된 파일의 URL 경로를 통해 해당 파일을 직접 실행 가능.플래그 파일 경로 탐색:/flag 파일이 서버에 존재하며, 이를 탐색 및 읽어야 함.공격 과정1. 웹셸 작성:system() 함수로 서버에서 명령어를 실행.URL 파라미터 id를 통해 명령어 전달.2. 웹셸 업로드웹셸 파일(webshells.php)을 업로드:업로드된 파일의 URL: http://war.knock-on.org:10007/uploads/file_678c..

문제 정의Flask 기반 웹 애플리케이션에서 /increase 엔드포인트를 익스플로잇하여 플래그 획득이 목표.카운터 시스템:초기 카운터 값은 0으로 시작./increase 요청마다 카운터가 1씩 증가.카운터가 15 이상일 때 플래그 반환.공격 기법: 레이스 컨디션(Race Condition)레이스 컨디션이란?동시성 문제가 발생하여 두 개 이상의 요청 또는 스레드가 동일한 자원(예: 카운터 변수)에 동시에 접근.요청 처리 간 락(Lock) 없이 동작할 경우, 변수 값이 예상과 다르게 처리되거나 비정상적으로 증가.문제 분석서버 동작/increase 엔드포인트:카운터 값을 1 증가.0.1초 지연(sleep(0.1)) 후 값을 저장.카운터 값이 15 이상일 경우 플래그 반환.멀티스레드 환경:여러 요청이 동시에 ..

IDOR란?Insecure Direct Object References (IDOR)는 웹 애플리케이션에서 발생하는 보안 취약점으로, 인증된 사용자가 다른 사용자의 데이터나 리소스에 접근할 수 있도록 허용하는 문제입니다.취약점 특징보통 URL, 요청 파라미터, 또는 쿠키에 포함된 식별자(ID) 값이 제대로 검증되지 않을 때 발생.사용자가 자신의 권한 범위를 벗어나 다른 사용자의 데이터를 열람하거나 조작 가능.문제 해결 과정1. 회원가입 및 로그인시작: 웹사이트에 회원가입 후 로그인.로그인 후 개인 게시물만 확인 가능한 상태에서 취약점 여부를 조사.2. 게시물 ID 확인URL 분석:게시물 접근 시 /post/{ID} 형태의 URL 사용: /post/11 이 구조는 ID 값이 다른 사용자의 게시물에 접근 가능..

목표서버의 비즈니스 로직 취약점을 이용하여 잔액을 조작하고, 고가의 플래그를 성공적으로 구매.문제 분석애플리케이션 동작상품 구매 기능: 사용자는 잔액 내에서만 상품 구매 가능.플래그 가격: 플래그는 매우 높은 가격(예: 9,999,999원)으로 설정.기본적으로 제공된 잔액으로는 플래그 구매 불가.초기 확인정상적인 구매 시도:잔액 부족 시 구매 불가 메시지 출력.서버에서 잔액을 검증하는 로직 존재.공격 과정1. Burp Suite를 사용한 요청 가로채기분석 대상: /store/{item} 경로로 전송되는 POST 요청.요청 내용: quantity: 구매 수량을 나타내며, 기본적으로 양수 값(예: 1)으로 설정.요청 차단 시, 서버는 잔액 부족을 이유로 구매를 거부.POST /store/flag HTTP/..

문제 정의Flask 애플리케이션에서 **SECRET_KEY**가 환경 변수 FLAG로 설정.초기 분석 시, FLAG 값이 가짜 플래그로 보였으나 실제 플래그였음.목표: SSTI 취약점을 이용해 SECRET_KEY를 노출시키고, 플래그를 획득.문제 분석Flask 애플리케이션 취약점SSTI(Server-Side Template Injection)사용자 입력이 Flask 템플릿 엔진 Jinja2에서 실행됨.입력값이 서버에서 적절히 필터링되지 않고 실행되며 발생.플래그 저장 방식SECRET_KEY에 환경 변수 FLAG 값이 설정됨.Flask의 config 객체를 통해 SECRET_KEY 값을 확인 가능.플래그 획득 과정1. SSTI 취약점 확인기본 테스트: SSTI 취약점 여부를 확인하기 위해 템플릿 코드 테스..

목표Flask 애플리케이션에서 SSTI(Server-Side Template Injection) 취약점을 이용하여 서버의 중요한 정보에 접근하고, 환경 변수에 저장된 플래그를 획득.문제 개요Flask 애플리케이션 취약점Flask 코드 분석 결과:render_template_string 메서드가 사용자의 입력을 그대로 템플릿으로 렌더링.사용자 입력이 필터링 없이 서버 측에서 처리되는 것이 확인됨.환경 변수:app.secret_key가 환경 변수 FLAG로부터 값을 받아 설정됨.이를 통해 플래그가 환경 변수에 저장되어 있음을 유추.플래그 획득 과정1. SSTI 취약점 확인기본 테스트: SSTI 여부를 확인하기 위해 간단한 템플릿 인젝션을 시도: 결과: 서버가 49를 반환하며, 사용자의 입력이 템플릿으로 렌..

목표SQL 인젝션 기법을 사용하여 admin 계정으로 로그인.LOGIN_FLAG를 획득.환경애플리케이션은 다음과 같은 필터링 리스트를 사용하여 SQL 인젝션 공격을 방어합니다:필터링 리스트filtering_list = ['or', 'and', '\'', '"', ' ']or, and: 논리 연산자가 필터링됨.작은 따옴표(')와 쌍따옴표("): 문자열을 감싸는 따옴표가 필터링됨.공백( ): 공백(띄어쓰기)이 필터링됨.SQL 쿼리 구조 SELECT * FROM user WHERE username = '{username}' AND password = '{password}'사용자가 입력한 username과 password 값이 SQL 쿼리에 삽입되어 인증이 이루어짐.우회 전략1. 공백을 주석(/**/)으로 대체..