이번에는 파일 업로드와 안전하지 않은 캡차 취약점을 알아보는 시간을 갖겠습니다.
발표에 사용한 PPT 파일을 첨부합니다. 해당 PPT 파일 초반부에는 이전 PPT 파일에서 미흡했던 파일 인클루전에 대한 내용도 담겨있습니다. 19 페이지부터 확인해주시기 바랍니다.
이 발표 과제는 AI 스쿨의 리팩토링 과정에 따라 진행하혔습니다. 수업 내용과 커리큘럼에 대하여 더 많은 정보를 얻고 싶으시다면 다음 링크를 통해 AI 스쿨을 알아봐 주시기 바랍니다.
https://cafe.naver.com/itscholar
File Upload 취약점
파일 업로드 취약점이란, 업로드 하는 파일에 대한 검증이 부족하여 악의적인 파일을 웹 서버에 업로드하고 실행할 수 있는 취약점을 말합니다. 파일 업로드 취약점이 존재할 경우, 공격자는 이를 이용하여 웹 서버에서 권한을 탈취하여 시스템 내부에 있는 자료들을 열람하거나 오염하거나 삭제하는 등의 조작이 가능합니다.
이번 실습을 진행하기 위한 계획은 다음과 같습니다.
1. 악의적인 스크립트가 있는 파일 작성
2. DVWA에 파일 업로드
3. 업로드된 파일을 웹 상에서 호출하기
여기서 1번 파일은 이전 시간 파일 인클루전에 사용했던 test.php 파일을 그대로 사용하겠습니다. 참고호 해당 파일의 내용물은 다음과 같습니다.
파일을 이제 File Upload 탭에 접근하여 업로드 기능을 이용하여 업로드 해 줍니다. 그러면 업로드 경로가 나타나면서 성공적으로 업로드 되었다는 메세지를 확인할 수 있습니다. 이제 업로드 경로대로 웹 상에서 URL을 입력해 준다면
서버에서 업로드한 파일을 실행하여 중요한 파일이 유출되는 것을 확인할 수 있습니다. 파일 업로드 취약점에 대응하기 위해서는 다음 방안들을 고려할 수 있습니다.
업로드 한 파일 검증하기
업로드 한 파일을 검증해야 합니다. 주로 파일 확장자를 검증하여 악의적으로 사용될 수 있는 파일 확장자를 검열하는 방식입니다.
실행 권한 조정
실행 권한을 조정하여 서버 외부에서 해당 파일을 실행할 수 없도록 해야 합니다.
서버 환경 분리
웹 서버와 업로드 서버를 분리하여 운영한다면 설령 문제가 발생하더라도 서비스 피해를 최소화 할 수 있습니다.
Insecure CAPTCHA
안전하지 않은 캡차 취약점입니다. 이는 캡차 테스트를 우회할 수 있는 취약점을 말합니다. 정상적으로 진행하려면 캡차 테스트를 통화해야 작동시킬 수 있는 기능이 캡차 테스트를 무시하고도 진행할 수 있슨 경우를 말합니다.
실습을 진행하기 위해 Insecure CAPTCHA 탭에 접근합니다. 해당 탭에선 비밀번호를 변경할 수 있는데 캡차를 통해서 이 행위가 자동화된 스크립트로 진행되지 않도록 방어하고 있는 모습을 볼 수 있습니다. 비밀번호를 1234로 변경하기 위해 우선 캡차 테스트를 통과해봅시다. 그러면 다음 페이지를 볼 수 있습니다.
캡차 테스트를 통화했으니 비밀번호를 바꿀 수 있다는 메세지를 확인할 수 있습니다. 이제 체인지 버튼을 클릭한다면 비밀번호가 변경됩니다.
버프 스위트에서 해당 패킷들을 분석한다면 패킷의 구조가 세 단계로 나뉘어 있는 것을 확인할 수 있습니다. 여기서 두번째 페이지의 패킷에 접근한다면 해당 페이지도 변경할 비밀번호에 대한 정보를 담고 있는 것을 확인할 수 있습니다.
여기서 첫번째 패킷을 건너 뛰고 두번쨰 페이지의 양식으로 요청을 제작하여 전송한다면 해당 요청에 따라 비밀번호가 변경되는 것을 확인할 수 있습니다. 비밀번호를 1111로 변경하고 전송해 보도록 하겠습니다.
로그인에 성공했습니다.
안전하지 않은 캡차 취약점을 극복하려면 이번 취약점에서 보듯이 캡차 인증이 필요한 페이지를 여러 패킷으로 나누어서 해서는 안됩니다. 그리고 더 중요한 바는, 근본적으로 캡차 인증을 신뢰해서는 안된다는 점 입니다. 캡차 인증은 인터넷에서 자동화된 봇들이 트레픽을 과하게 사용하는 것을 막기 위해서 도입하는 도구이지 더 나은 보안 체계를 만들기 위한 도구가 아닙니다.
현대의 여러 자동화 도구들이 발전하여 이제 캡차 인증은 유명무실해지고 있습니다. 이런 상황에서 비밀번호와 같은 중요한 정보를 바꾸는 페이지를 캡차 인증 같은 도구로 보호해서는 안됩니다, 비밀번호 변경과 같이 중요한 페이지에는 다른 2차 인증 수단을 마련하는 것이 더 나은 방향입니다.
'AI 스쿨 리팩토링 보안직무 과정' 카테고리의 다른 글
39주차 과제 - SQL Injection (LOW) (0) | 2024.03.24 |
---|---|
37주차 과제 - 웹 모의해킹 CSRF, File Inclusion (LOW) (2) | 2023.11.27 |
36주차 과제 (하) - Brute Force 공격, Command Injection 공격 (LOW) (1) | 2023.11.21 |
36주차 과제 (상) - DVWA, KALI LINUX 설치 (1) | 2023.11.07 |
35주차 과제 - 프록시 서버 (0) | 2023.10.31 |
댓글