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

이번 포스팅은 Base 64 인코딩 복호화, Html 5 웹 저장소, 파일텍스트 중요정보 저장에 대해 해보려고 한다. 조금 말이 복잡해 보이는데 크게 어렵진 않은 내용들이다. 

1. 클라이언트에 암호화하지 않고 서버에 암호화 하는 이유는?

- 클라이언트에서 암호화를 해서 서버로 전송을 하게 되면 클라이언트가 해커인지 사용자인지 분간할 수 없다. 서버에서 암호화를 하기는 하지만 보안상 완벽하다고 말하기는 힘들다.

- 클라이언트에서 암호화하게 되면 중간에 해커가 가로채는 하이재킹공격을 시도할 수 있기 때문에도 되도록이면 서버에서 암호화 할 수 있도록 하는게 좋다.

* 공격 실습

1) Base 64 Encoding(Secret)

일단 Base 64 Encoding(Secret)를 선택하고 보안레벨을 Low로 맞추고 프록시를 잡아주면 secret값이 나온다. 이걸 그대로 복사해준다.

이걸 그대로 Base64 Docoder기에 넣어주면 바로 해독된다는 것을 볼 수 있다.

잠깐 비박스에서 Base64에 대한 코드를 보면 보안레벨이 1,2일땐 sha1으로 비밀번호를 정의한다고 했는데 sha1은 얼마든지 해킹이 가능하기 때문에 사실 이것도 보안이라고 보긴 힘들다. base64 인코드 역시 바로 번역기로 해킹이 가능하기 때문에 안전한 보안이라고 할 수 없다.

medium에 세팅해놓고 프록시를 잡아봤을때도 아까와 별다를게 없어보인다. 이걸 Hash에 넣고 확인해본다.

리눅스에 hash를 실행시켜서 secret문자를 붙여넣어보면 비밀번호가 sha1으로 되어 있음을 알 수 있다.

이 값을 그대로 sha1 디코더에 넣어서 실행시켜 보면 바로 비밀번호가 해킹됐음을 알 수 있다. 여기서 제일 중요한건 웹환경을 구축할 때 민감한 평문데이터들을 local에 저장하면 절대 안된다는 것이다. local에 저장했을시 이렇게 쉽게 해킹되기 때문에 구축할때 주의가 필요하다.

Xss공격으로도 쉽게 security값을 알아낼 수 있다.

물론 보안레벨이 높아짐에 따라 조금씩 좋아지긴 하지만 어쨌든 local에는 평문으로 민감한 데이터를 저장하지 않는게 핵심이다.

2) Html5 web Storage(Secret) 공격

일단 보안레벨을 Low로 맞춰준다.

그리고 text에 이렇게 코드를 삽입해준다.

Xss-Reflected(Get)으로 와서 방금 입력한 코드를 Firstname에  넣어서 실행해보면 이런식으로 나오는데 이 또한 아까와 똑같은 sha1값이 그대로 출력된다는 걸 알 수 있다. Xss공격에 대한 방어가 안되고 있음을 보여주고 있으며 medium, High로 올려봤을땐 전혀 sha1값이 나오진 않았지만 local환경은 항상 유의해야 함을 볼 수 있었다.

3) Text Files(Account) 공격

아이디와 비밀번호를 입력하고 보안레벨은 low로 맞춰준다.

다운로드를 클릭해서보면 사진처럼 bee bug만 나온다.

이번에는 medium으로 맞추고 다운로드를 클릭해본다.

이번에는 알수없는 문자가 나왔지만 hash에 넣어보면 이 역시 sha1이다. 바로 해독기에 넣고 돌리면 비밀번호가 추출된다.

이런식으로 추출이 완료된다. sha1으로 된 비밀번호는 역시 위험하다.

이번에는 보안레벨을 High로 맞춰놓고 다운로드를 해본다.

이번에는 salt까지 추가되었음을 볼 수 있다. Hash 비밀번호를 Hash에서 어떤식으로 되어 있는지 확인해 보도록 하겠다.

아까와는 다른 SHA-256으로 되어 있는데 이렇게 SHA-256으로 되어 있는 비밀번호들은 비교적 많이 안정하다고 평가 받고 있다. 아까 나온 salt 비밀번호와 같이 합쳐줘서 계산해줘야 되기 때문에 해독이 쉽지 않아 이런식으로 되어 있으면 보안등급이 높다고 평가 할 수 있다.

SHA-256을 해독하기 위해 john이라는 툴을 사용해봤는데 해독하기 쉽지 않았다. passwd.txt에 Hash값을 넣고 저장해서 salt값을 같이 넣어서 실행해줬는데 시간도 너무 오래 걸리고 잘 해독되지 않았다. 이처럼 hash값이 SHA-256으로 되어 있으면 안전하다고 평가할 수 있을 것 같다.

이번에는 중요정보를 변경 및 초기화하고 상품가격을 조작하는 공격에 대해 알아보려고 한다.  먼저 이러한 해킹들의 대표적인 실제 사례가 있어 제시한다.

<실제 사례>

<사진출저:Google 나무위키 사전백과>

2014년에 있었던 KT 최악의 개인정보 유출사건이다. 이 당시에 1200만명의 엄청난 고객 정보들이 유출 되었으며 그중 일부는 다른 회사에 판매하는 방식으로 이익을 챙겨 일당들이 전부 구속된 사례이다. 이게 어떻게 해킹 되었는지는 아래에 실습과정을 쓰겠지만 사실 어떻게보면 해킹이라고 보기에도 너무 애매하다. 오늘 실습했던게 보통 로그인을 할 때 과연 그 사용자가 맞는지, 해커는 아닌지에 대해 검증하고 필터링 하는 과정이 필요한데 KT는 이 당시에 이러한 검증절차를 거치지 않고 DB의 내용만 믿고 숫자만 맞으면 로그인을 시키게끔 했던 시스템이었다. 그러다보니 파로스프로그램, 즉 본인이 사용하고 있는 버프스윗과 거의 차이가 없는 툴이었다. 이 툴을 바탕으로 고유숫자 9개를 아무거나 입력시켜서 가입고객 고유번호를 맞춰서 고객정보를 유출시킨 사건이었다.

<공격실습>

(1) InSecure DOR(Change Secret) 공격

비밀번호 바꾸기 공격이다. 사용자인줄 알고 DB인증 절차 없이 바로 비밀번호 변경이 가능한 실습이다. 보안레벨을 low로 맞춰주고 test1234라는 값을 입력하고 change버튼을 눌러준다.

전에 했었던  SQL 인젝션 로그인폼으로 와서 bee, bug를 입력해주고 로그인하면 저런식으로 Test1234라고 비밀번호가 바로 변경된 것을 볼 수 있다. 인증절차 없이 DB정보만 맞으면 그냥 바꿔준 것이다.

이번에는 'or 1=1# 공격문을 써서 로그인을 해보니 아이디는 AIM이라고 나오고 비밀번호는 아까 입력한 test1234가 나오게 된다. 비밀번호를 한 번 변조해 보겠다.

InSecure DOR로 다시 와서 바꿀 비밀번호를 입력하고 프록시를 잡아준다. 그리고 프록시를 잡아준 곳을 보면 login이라는 곳이 있는데 여기에다가 아까 변조하려고 했던 A.I.M.을 넣어주고 포워딩시킨다.

그리고 SQL 인젝션으로 다시와서 아까와 똑같이 로그인을 해보면 저런식으로 Test4321로 비밀번호가 변경된 것을 볼 수 있다. DB내용만 맞으면 로그인이 되어서 저런식으로 변조가 가능했던 것이다.

이번엔 보안레벨을 medium으로 맞추고 프록시를 잡아보았다. medium레벨에서는 아까와는 다르게 token이라는 값이 잡혔는데 이 token값을 활용해서 검증절차를 한번 더 짚어보겠다는 의미로 해석된다. low와는 다르게 한단계정도는 보안이 강화된 상황이다. 

<대응방안>

비박스에 들어가서 insecure_direct_object_ref_1.php파일을 열어보면 보안레벨이 low일때 어떤방식으로 처리하고 있는지에 대해서 알 수 있다. $sql쪽을 보면 login이 되면 별다른 검증절차 없이 어떠한 아이디라고 패스워드를 바꿀 수 있다. 이러한 방식은 매우 위험한 코드라고 보면 된다. 검증절차를 거치게 하는 코드를 짜야한다. 그래도 Xss공격에 대해서는 방어를 하고 있는 상태이다. escape함수, htmlspecialchars함수를 사용했으며 어느정도 Xss공격에 대해서는 대비가 되어 있는 상태라고 볼 수 있다. 

이번에는 Medium과 High레벨 상태의 코드이다. 아까와는 다르게 token이라는 값을 삽입해 세션을 검증하는 절차를 거치고 있다. 세션이 검증되지 않으면 로그인 정보로 넘어갈 수 없는 상태이다. medium, High레벨 상태도 Xss공격에 대한 대해서는 대비가 되어 있는 것을 볼 수 있다. 하지만 이 코드도 그렇게 안전하지는 못하다고 생각한다. sql쪽에서 문제가 발생할 수 있는데 login이라는 정보를 프록시에 삽입해주기만 하면 우회해서 또 변경이 가능하다.

test1234를 입력하고 프록시를 잡아준 화면인데 여기에 login할 아이디를 입력해준다. 그리고 포워드를 해준다.

그렇게 되면 이런식으로 또 한번 비밀번호가 변경되었음을 볼 수 있다. 그래도 검증절차를 거치는 것은 기본이라 보안레벨이 조금이라도 높다고는 할 수 있지만 이런식으로도 해킹이 얼마든지 가능하기 때문에 이러한 해킹을 막는건 조금 더 생각해 봐야 할 문제 일 것 같다.

(2)  InSecure DOR(Reset Secret) 공격

Reset Secret공격도 아까 했던 공격과 크게 다르진 않다. 프록시를 잡아주고 변조할 아이디를 넣고 Forword를 해준다. 

SQL 인젝션쪽으로 와서 로그인해서 확인해보면 저런식으로 비밀번호가 변조되었음을 알 수 있다.

이번에는 medium으로 맞춰놓고 프록시를 잡은상태인데 바꿀비밀번호를 aaa로 놓고 포워딩을 해줬다.

A.I.M.으로 로그인을 해보니 비밀번호가 전혀 바뀌지 않고 아까와 그대로 임을 볼 수 있다. 

<대응방안>

 insecure_direct_object_ref_3.php 파일을 열어보면 다음과 같은 코드들이 있다. 좀 두드러진 특징이 Content-type를 사용해서 데이터를 보내주고 있다는 것인데 Post방식을 사용할때는 xxe-2.php로 보내준다고 코드가 짜여져 있다. 

xxe-2.php 파일을 열어보면 이런 코드가 나오는데 보안레벨이 low일때를 보여주고 있다. 아까와 같이 비밀번호가 손쉽게 변경된 이유도 DB 검증절차를 전혀 거치지 않고 있다.  xml에서  login, secret으로 아무런 검증없이 로그인만 되면 바로바로 변경이 가능할 수 있다. 검증절차를 거치지 않는 코드는 보안레벨이 가장 낮은 코드라고 보면 된다.

반대로 보안레벨이 조금 높아진 경우의 코드이다. 아까와는 다르게 login값을 세션에 묶어 검증하는 절차가 있음이 눈에 띄게 보이게 된다. 이런식으로 반드시 검증하는 절차의 코드가 있어야 그래도 조금 안전한 레벨의 보안수준이라고 할 수 있을 것 같다.

(2) InSecure DOR(Order Ticket) 공격 -> 상품가격조작 공격

이 공격도 매우 간단하지만 홈페이지에 있는 가격을 변조해서 물건을 구입하려는 블랙해커들이 자주사용하는 방법이다. 실사이트에 공격해 물건값 변조해서 구입하면 이 역시 교도소행이니 알아만두고 절대 사용하면 안된다!

이렇게 프록시를 잡아주고 프록시에서 ticket값을 1로 변조하고 포워딩을 시켜준다.

이렇게 되면 아까는 15유로였는데 1유로로 변조되었음을 알 수 있다.

<대응방안>

레벨이 가장 낮은 보안수준일때는 ticket_price를 그냥 입력되는 그대로 전부 다 보내주고 있다. 아무런 검증절차를 거치지 않고 그냥 로그인정보만 믿고 보내주는 셈이다.

반면 보안레벨이 medium, High일때는 ticket_price를 입력된 값 그대로 보내주겠다는 코드이고, 그렇지 않으면 안보내겠다는 코드이다. 즉, Request라는 검증절차를 거치고 보내주겠다는 의미로 해석된다.

이번에는 Xss공격(Reflected)에 대해 포스팅하려고 한다. Stored에서도 설명했듯이 Reflected공격도 큰차이는 없지만 사용자에게 악의적인 코드를 심어 그걸 클릭하게끔 유도한다는 방식은 비슷하기 때문에 어떤 공격이 있는지 알아본다.

1. Xss공격(Reflected)

- 사용자에게 악의적인 코드를 심어 클릭하게 유도해서 세션정보를 빼내는 공격 

- 사용자에게 공격해서 다시 반환되어 돌아온다는 것이 특징이며 돌아오는 것은 세션정보, 로그인정보 같은 것이다.

<출저: 보안프로젝트>

* Xss-Reflected 공격 실습

(1) Xss - Reflected(Get) 공격

이 공격도 앞서 SQL 인젝션에서 했던  Get 공격과는 큰차이는 없다. 

First name, Last name에 경고창을 띄워주는 코드와 쿠키값을 볼 수 있는 코드를 입력해주고 실행을 하면 사진과 같이 쿠키값이 나온다는 것을 볼 수 있다. 위에 입력한 스크립트 공격은 많이 쓰이는 코드를 외우는 것도 좋다. 

보안을 High로 설정했을시에는 쿠키값이 노출되지 않고 입력했던 코드가 그대로 보여지는 것을 볼 수 있다. 

(2) Xss - Reflect(Post)공격

Post공격은 프록시를 잡아줘야 하기 때문에 저렇게 값을 넣고 버퍼스윗을 이용해 프록시를 잡아준다.

fitstname,Lastname에 쿠키값을 알아내는 코드를 입력해주고 Intercept off를 눌러준다.

이런식으로 쿠키값을 알려주는 경고창이 뜬다. 이런식으로도 쿠키값을 가져오는 것을 알 수 있다. 보안레벨이 High로 맞추고 프록시를 잡고 실행하게 되면 쿠키값이 뜨지 않고 입력한 코드가 뜨는 것은 Get방식 보안과 다를건 없다.

(3) Xss - Reflected(JSON) 공격

Reflected(Json) 공격도 다른 공격들과 큰차이는 없지만 저렇게 아무거나 조회하게 되면 결과값이 안나온다. 데이터베이스에 있는 값들만 조회가 가능하다. 

사진과 같이 명령어를 입력해준다. 단지 차이점이 조금 있다면 앞에 </script>를 입력하고 뒤에 <script>를 한번 더 입력했다. 뒤에는 차이가 없다.

저 값을 실행해보면 다음과 같이 경고창 메시지가 나오게 된다. Json 공격으로도 역시 쿠키값이 탈취가 가능함을 보여주는 공격이다.

(4) Xss - Reflected(AJAX/JSON) 공격

이 공격 또한 프록시를 잡아줘야 한다. 쿠키값을 검색하는 명령어를 입력하고 프록시를 잡아준다.

이런식으로 프록시를 잡아주게 되는데 입력한 스크립트 공격코드가 잘 입력됨을 볼 수 있으며 Ajax특성을 잘 살렸다는 것을 볼 수 있다.  주소창에 xss_ajax_2-2부터 title값까지 복사해주고 URL뒤에 넣어주면 된다.

이런식으로 또한 Ajax 공격으로도 쿠키값을 알아낼 수 있다.

이번에는 medium으로 맞춰놓고 아까 카피한 ajax 2-2 주소값을 그대로 넣어서 실행시켰다.

이번에는 이렇게 php파일을 다운로드 하라는 형식으로 나오게되서 쿠키값을 알아내기가 불가능해졌다. 

보안레벨을 High로 맞춰놓고 실험을 했다. 아까와 똑같이 주소값을 입력해주고 실행해준다.

실행해주면 &lt와 같은 값이 나와 쿠키값 탈취가 불가능해짐을 알 수 있다.

<대응방안>

비박스에서  xss_ajax_2-2.php파일을 보면 보안레벨이 높을수록 방어가 잘되어 있다는걸 볼수 있다. 제일 두드러진 특징이 header값을 넣어주었다는 건데 Content-type을 이미 명시를 해주었다. 그렇기 때문에 text/json을 실행하려고 해도 공격자가 넣은 스크립트를 실행할 수 없고 데이터를 실행하는 것이 되기 때문에 전혀 쿠키값을 알아낼 수 없는 것이다.

보안레벨이 medium일때도 마찬가지로 header안에 Content-type를 넣어줘서 악의적인 목적으로 삽입된 자바스크립트가 동작할 수 없도록 해주고 있다. 반면 보안레벨이 low일때는 전혀 보안이 안되어있고 무방비로 쿠키값이 탈취당하게 될 수밖에 없는 구조이다.

이번엔 이미지를 삽입한 공격이다. 이미지가 없기 때문에 저런식으로 빈상자가 나오게 된다. 

명령문 뒤에 onerror='alert(1)>이라는 것을 추가해줬더니 저런식으로 악의적 자바스크립트가 삽입이 되었다. 이미지가 없으면 1을 출력하라는 명령어이기 때문에 계속 경고창이 뜬다는 것을 볼 수 있다.

(5) Xss - phpmyadmin 공격

이번엔 phpmyadmin공격이다. 이 공격도 악의적으로 어떠한 버튼을 만들어 이상한페이지로 이동하게 해서 세션을 탈취할 수 있기 때문에 알아두면 좋은 공격이고 방어를 할 수 있게 될 것이다.

이런식으로 URL주소값을 입력해주고 type을 추가해주면 저런식으로 만들 수 있다.

뒤에 코드를 조금 더 추가해줘야 하는데 비비코드형식으로 입력해줘야 한다. [a@http://10.0.2.4/bWAPP/attack.php@]click[/a] 이런형식으로 뒤에 입력을 해준다음 실행해주면 click이라는 버튼이 생기게 된다.

실행해주면 이렇게 mysql 정보를 전부 탈취할 수 있게 된다. 

(6) Xss - PHP_Self 공격

이 공격도 다른것과 크게 다르진 않다. 쿠키값을 탈취하는 코드를 넣어서 실행해준다.

실행이 되면 이런형식으로 쿠키값이 탈취됨을 볼 수 있다.

<취약점 분석>

화면에 보면 form action 뒤에 server라는 변수가 있는데 php_self를 받아서 자기 자신을 실행시키게끔 변수를 받고 있다. 하지만 이 방식은 편의성이 제공될 수는 있지만 사용자에게는 취약점이 발생할 수 있다.

URL에 악성자바스크립트를 넣어서 실행한다.

실행이되면 이런식으로 악성자바스크립트가 삽입되어 경고창이 뜬다는걸 알 수 있다. Php Self는 편리함도 있지만 이런식의 취약점도 발생할 수 있기때문에 보안에 더 각별히 신경써야 한다.

(7) Xss - Reflected(HREF) 공격

HREF공격은 공격이 좀 특이한 것 같았다. 다른것과 별다를바는 없었지만 vote라는 곳에 마우스를 갖다 대기만해도 악성코드가 삽입된 자바스크립트 경고창이 나와 이 또한 위험하다고 생각했다. sun이라고 검색해주면 저렇게 목록들이 나온다.

이번에는 Sun onmouseover=alert("xss") a를 검색해서 실행한 결과이다. Vote라는 곳에 마우스를 갖다 대면 저런식으로 자바스크립트 경고창이 나오게 되어 공격이 된다.

<취약점 원인>

마우스 우클릭을 해서 페이지 소스를 보게 되면 방금 삽입시켰던 코드를 볼 수 있다. 저게 원래는 vote라는 값으로 되어 있었지만 a href취약점을 이용해 뒤에 자바스크립트 코드를 삽입시키면 방금과 같이 경고창이 삽입될 수 있다.

이렇게 Reflected공격도 엄청나게 다양하다는 것을 포스팅해봤다. 공격법이 워낙 다양해 많은 내용이었다. 하지만 실습으로 끝나지 않고 왜 취약한지, 취약점을 강점으로 바꿀 수 있는 방법이 무엇이 있을지 어떤 함수를 써야 보안이 잘되는지에 대해 조금 더 분석하는 습관을 기르면 언젠가는 보안 보고서 같은 것도 잘 쓸 수 있지 않게 될까 생각한다.

이번에는 XSS Stored공격에 대해 포스팅해보려고 한다. XSS공격이 주로 자바스크립트를 이용해 악의적인 코드로 변조해서 공격하는 방법이다. 특히 Stored공격은 게시판에 댓글, 게시글, 쪽지 등에 악성코드를 삽입해서 공격하는 기법이다. 

1. XSS Stored 공격이란?

- 게시판과 같은 곳에 댓글, 게시글, 쪽지 등에 악성코드를 주입해서 공격하는 기법이다. 주로 자바스크립트를 활용한 공격이다.

- 자바스크립트를 활용해서 많은 공격이 이루어지고 있으며 보안레벨이 높아진다해도 html공격은 쉽게 막을 수가 없는 것이 특징이다.

- 공격자가 자바스크립트를 활용해 XSS공격을 하면 사용자도 모르게 그것을 클릭하게 되는데 세션, 쿠키정보를 뺄 수 있기 때문에 사용자 정보 등을 해킹이 가능하기 때문에 매우 위험한 공격이라고 볼 수 있다.

* XSS Stored 공격 실습

(1) XSS - Stored (Blog)

게시판을 이용한 공격이라고 설명했지만 SQL 인젝션에서 했었던 공격하고는 큰 차이는 없다. 화면에 보이는 것처럼 입력해주면 경고창에 1이라고 뜨면서 게시판에는 쿠키 정보들이 전부 기록되어 있는 것을 볼 수 있다. 이건 보안레벨이 가장 낮았을 때의 이야기지만 저런식으로 바로 쿠키가 노출되는 사이트는 사실상 보안을 전혀 안해놨다고 봐도 무방할정도로 위험하다.

가장 기본적인 XSS 공격방법이다. alert(1)을 줘서 저런식으로 1이라는 경고창이 뜨게 되는 것이다. 

<대응방안>

보안레벨이 높을때는 xss_check_3를 사용해서 공격을 무력화 시켜서 그대로 소스코드를 반환하는 방식으로 하고 있지만 보안레벨이 낮을때는 entry로 그냥 반환해 쿠키값이 전부 노출되게 되어 있다. 보통 보안레벨이 높은 코드는 html을 활용한 공격도 무력화 시킬 수 있다. htmlspecialchar함수가 html을 활용한 공격을 무력화 시킬 수 있는 가장 안전한 코드이다.

보안레벨이 High일때 아까 쿠키값을 얻으려고 입력했었던 코드가 그대로 노출되서 쿠기값 확인이 불가능하다는 것을 볼 수 있다.

(2) XSS - Stored (User-Agent) 공격

User-Agent Switcher을 구글에서 검색해 다운받고 사진과 같이 입력해주고 ok버튼을 누른다. User-Agent공격방식도 해커들 사이에서 꽤 사용되고 있는 방법이기 때문에 알아두면 좋다.

프록시를 잡아서 입력한 값이 맞는지 userAgent를 확인해주고  Forward를 눌러주고 프록시를 off해준다. 

그렇게 되면 사진과 같이 쿠키정보를 탈취할 수 있다. 하지만 보안레벨이 High로 되었을 시에는 쿠키정보가 나오지않고 입력한 코드가 그대로 출력됨을 볼 수 있을 것이다. 이 또한 대응방안은 위에서 작성한 것과 동일하다. 

Xss-Stored 공격에 대해 살펴봤는데 여러가지 수법으로 공격할 수 있는 방법이기 때문에 항상 유의해야 하며 Xss 공격자체가 OWSAP10에서 3위를 차지할 정도로 매우 강력한 공격이기 때문에 보안레벨이 높은 함수들을 써서 방어하는 것이 최선이다. 본인도 XSS공격에 대해 좀 더 많이 살펴보고 사례들은 어떤것들이 있는지에 대해서도 꾸준히 공부해 볼 생각이다.

이번에는 세션결함에 대해 포스팅해보려고 한다. 로그인할때 아이디, 패스워드 입력없이도 세션만 알아낸다면 바로 로그인이 가능하기 때문에 세션이 해킹되게 되면 많은 문제를 야기할 수 있다. 세션자체가 한번 사용되면 버려지는 것이기 때문에 조금만 신경써서 보안을 설정해놓으면 큰 문제는 없지만 요즘 블랙해커들은 수법이 우리가 상상할 수 없을 정도로 고도화되어 있기 때문에 서버를 개발할 때도 항상 신경써서 개발해야 한다. 

1. 세션결함이란?

-  세션을 탈취당하는 행위이며, 가장 많이 도출되는 취약점 중 하나이다. 보통 세션관리미흡에서 많이 발생한다.

- 관리자 페이지에 대해 접근할 때 가장 많이 나오는 취약점 중 하나이다.

- 회원가입을 할 때 항상 아이디 비밀번호가 맞냐고 페이지 창으로 물어보는 경우가 있는데 이런식으로 보안 설정을 해      놓아야 세션이 탈취당할 일이 없다. 세션은 한 번 사용되고 폐기되는 것이기 때문에 물어봄과 동시에 또 한 번 세션이        바뀌게 된다.

* 세션결함 공격 실습

(1) Session Mgmt - Administrative Portals 공격

세션에 대한 실습은 의외로 간단하다. 그만큼 세션을 탈취하는 자체가 어렵지 않다는 반증이기도 하다. 현재 보안레벨이 low로 설정되어 있는데 페이지가 Lock가 되어 있지만 URL을 보면 admin=0이라는 주소가 있는데 이것만 admin=1로 바꾸어주면 페이지가 풀리게 된다.

admin=1로 바꾸어주니 URL 페이지 접근이 허용되었다는 메시지가 나오게 된다.

이번엔 인증결함에 대해 포스팅해보려고 한다. 실습자체는 간단한데 이 공격방식 또한 많이 쓰여지는 방식이기 때문에 항상 주의가 필요하다.

1. 인증결함이란?

- 인증에 필요한 사용자의 계정정보를 노출하는 취약점

- HTML코드, GET요청 URL에 변수를 노출

- 취약한 암호 인증

- 취약한 인증 과정

2. 인증결함 공격 과정

<출저: 보안프로젝트>

공격플로우를 보면 인증과정 결함, 세션관리 취약점 등으로 사용자 권한을 획득해 로그인 해 정보를 빼내는 경우가 많기 때문에 항상 세션관리, 인증방식에 대한 보안 검토를 철저히 할 필요성이 있다.

* 인증결함 공격실습*

(1) Broken Auth(Insecure Login Forms) 공격

InSecure Login Form의 보안단계를 Low로 설정했을시에 특이한 현상이 발생한다. 저렇게 블록지정해놓은 곳을 보면 아이디 비밀번호가 그대로 노출되어 있다. 예전에 많이 사용하던 방식이라고 하는데 요즘에는 보안이슈에 예민하기 때문에 거의 사용하진 않는다고 한다. 사진에 있는 아이디, 비밀번호만 입력해주면 바로 로그인 되는 것을 볼 수 있다.

로그인이 되면 success라는 문구가 나오는게 보이면 정상적으로 실행된 것이다.

이번에는 보안레벨을 medium으로 설정했는데 이 역시도 금방 해킹할 수 있다. 아까처럼 눈에 보이게끔은 아니지만 페이지 소스를 보면 바로 비밀번호 해킹이 가능하다.

페이지 소스를 보면 뭔가 암호화 하는 코드가 보일 것이다. 코드를 분석해서 일일히 알아낼 수도 있기는 하지만 시간이 걸리기 때문에 블록지정한 코드들을 복사해서 크롬 자바스크립트 콘솔을 활용해서 비밀번호를 알아냈다.

자바스크립트 콘솔에 코드를 붙여넣고 alert(secret)라는 명령어를 넣고 실행하면 바로 비밀번호를 알아낼 수 있다. 저 비밀번호를 넣고 로그인을 하면 비밀번호가 바로 공개된다.

(2) Broken Auth - Weak Passwords 공격 (1)

말그대로 패스워드 취약점을 이용한 공격방법이다. 이건 프록시를 잡아서 해야 하는데 일단 칼리리눅스가 무료버전이기 때문에 스레드도 하나밖에 안되서... 비밀번호 해킹하려면 한 3~4일은 돌려야 가능할 것이다. 그렇기 때문에 하는 방법만 포스팅했다.

일단  bee, bug라고 입력하고 프록시를 잡아준다.

그리고 버퍼스윗으로 와서 send to intruder을 클릭해 intruder로 프록시들을 보내준다.

그리고 패스워드에만 $$를 지정해준다. 오른쪽 Add, Clear로 쉽게 설정할 수 있다.

Payload로 가서 타입을 Brute forcer로 바꿔준다. 이 타입은 좀 더 많은 공격을 할 수 있다. min,max length도 3으로 맞춰준다.(비밀번호가 3자리였기 때문에) 이렇게 설정해줘도 46656번을 돌아야 비밀번호 알아내기가 가능해진다.

옵션은 따로 지정해 줄 건 없지만 스레드가 하나기 때문에 비밀번호를 찾는데 엄청난 시간이 걸린다. 유료로 사게 되면 스레드 설정이 가능하기 때문에 좀 더 빨리 비밀번호를 찾아 낼 수 있을 것이다.

그리고 target으로 가서 start Attack를 눌러주면 저렇게 실행되면서 비밀번호를 찾는다. 이게 스레드가 1개여서 3~4일은 돌려야 알아내기가 가능할 것이다-_-;;

(3) Broken Auth - Weak Passwords 공격 (2)

사진에 보이는 것처럼 구글에 검색을 하고 userpassword-passwds-phpbb.txt순으로 들어간다.

그리고 리눅스 창으로 가서 wget함수를 쓰고 URL을 복사해서 저렇게 넣어주고 실행해준다.

버프스윗으로 가서 Payloads쪽에 타입을 이번엔 SimpleList로 지정해주고 받은 파일 phpbb.txt를 그대로 로드해준다.

그리고 Positions탭으로 와서 Start Attack을 실행해주면 다음과 같은 화면이 나오면 정상적으로 실행된 것이다. 저런식으로 자주 사용되는 비밀번호들을 하나씩 찾아내게 된다. 이 또한 엄청 오래 걸리기 때문에 그냥 하는방법만 제시해 놓을 생각이다. 

(4)  Broken Auth - Password Attack

password attack도 크게 다른 내용은 없다. 보안레벨이 Low로 되어 있으면 아무거나 입력해도 바로 로그인이 되는 현상이 발생한다.

반면 보안레벨을 High로 맞춰놓고 했을시에 캡차가 나오게 되는데 이렇게 되면 Bruth Forcing이 불가능해져서 비밀번호를 알아내기 힘들어지게 된다. 사용자가 보고 일일히 입력을 해야 하기 때문이다.

인증결함방식 공격도 좀 다양했는데 항상 사용자 인증, URL 취약점 노출에 주의해야 한다고 생각한다. 인증결함방식에 대한 이론도 많기 때문에 조금 더 찾아보고 공부해보면 좋을 것 같다.

이번 포스팅은 XML, XPath 인젝션에 대해 포스팅해보려고 한다. 사실 이 공격방식도 다른 공격들을 다뤘지만 많이 유사하고 크게 어렵지 않는 부분이다.

1. XML/XPath 란?

- XML구조에 악의적인 쿼리, 코드를 삽입해서 정보를 탈취하는 공격

- XML은 데이터를 트리구조로 표현한 것이 특징이며 XPath는 일종의 쿼리라고 생각하면 쉽다. 더 쉽게 설명하면 XML    은 데이터베이스이고 XPath는 SQL이라고 생각하면 훨씬 간단하고 편하다.

2. XPath 명령어

 <출저: 보안프로젝트>

XPath 명령어도 다양하게 있으므로 한번 참고용으로 보면 도움이 된다.

* 공격실습

1) XML/XPath 인젝션(Login Form) 

이 공격방식도 기존 공격방식이랑 비슷하다. 화면에 나온 명령어를 입력하고 로그인 버튼을 누르면 아래와 같이 화면이 잘 출력됨을 볼 수 있고 참일 경우에만 저런 화면이 나온다. 

만약 거짓임이 판별되면 화면처럼 빨간색 글자가 나오게 되면서 거짓임을 표시해준다.

2) 공격쿼리 실습

몇가지 공격쿼리가 있는데 neo' and count(../count::*) = 6 or 'a'='b 라고 입력해주면 저런식의 화면이 나오게 된다. ../은 상위디렉토리인 heros로 가서 heros에 있는 내용을 출력하겠다는 의미인데 그 값이 6인지 확인해보는 쿼리이다.

이번에는 neo' and string-length(name(parent::*)) = 6 or 'a'='b  라는 쿼리를 입력해주고 실행시켜도 저렇게 화면이 참으로 나온다. 길이를 알아보기 위한 쿼리인데 parent안에 있는 이름을 알아보려는 쿼리이다. 이 공격방식도 앞에서 설명한 Blind SQL인젝션 공격이랑 많이 흡사하다.

이번에는 neo' and substring(name(parent::*),1,1) = 'h' 'a'='b라는 쿼리를 입력해주고 실행시키면 참이 나오는데 substring에는 지난번에도 포스팅했지만 문자열을 알기 위한 함수이다. h라는 것이 첫번째 글자에 있기때문에 참이 나오는 것이다. 

3) XML/XPath(Search)실습

이번것도 별다른 건 없다. URL에 쿼리를 삽입하는 방식은 Blind 공격과 많이 흡사하다. 비박스  xmli_2.php파일로 들어가면 xpath 전달 경로를 볼 수 있다. 여기에 코드를 삽입해준다.

action이라는 부분에 공격할 쿼리인 ')] | //* | a[('를 삽입시켜주면 다음과 같은 화면이 조회된다. 그렇게 되면 heros에 있는 xml파일들이 다 조회가 가능하게 된다. 이런식으로 SQL 인젝션을 통해 xml파일 해킹 또한 가능하게 된다. 아래 사진은 heros.xml파일 내용이다. 이 부분들이 출력되는 것이다.

이렇게 XML/XPath 인젝션에 대해서도 포스팅 해봤지만 기존에 포스팅했던 공격들과 매우 흡사한 형태를 띠고 있다. XML변조 공격도 많이 이루어지고 있으니 항상 공부하고 대비하는 방법을 생각해보는 것이 좋을 것 같다.

이번에는 Blind SQL 인젝션에 대해 포스팅 해보려고 한다. Blind SQL 인젝션 공격 역시 활용도가 매우 높고 많이 사용하는 공격이기 때문에 취약점을 잘 찾아서 대비하는게 중요하다. 악의적인 쿼리를 삽입해서 사용자 id password를 알아낼수 있기 때문에 대비책이 어떤것이 있을지에 대해 고민해 봐야 할 것 같다.

1.  Blind SQL 인젝션이란?

- 쿼리의 결과를 참과 거짓으로만 판별시켜서 웹페이지를 공격하는 기법

- 출력내용이 참 아니면 거짓만 존재하기 때문에 데이터베이스의 내용들을 조작해서 공격하는 점이 가능하다는게 특징이다.

2. Blind SQL 인젝션 공격플로우

<사진출저: 보안프로젝트>

사용자 DB정보를 알아낼때 처음에는 참과 거짓으로만 판단해서 알아보고 해커가 어느정도의 길이가 필요한지 쿼리를 써서 알아내고 마지막에 최종적으로 아스키코드 쿼리를 대입시켜서 비밀번호를 찾아낸다. 이런 취약점이 발생하지 않도록 사전에 예방하는 것이 중요하다. 악의적인 쿼리가 어떤 것이 있는지, 어떻게 알아내는지 알아보자.

* 공격 실습*

(1) Blind SQL 인젝션 공격으로 쓰는 쿼리들

이런식으로 information_schema 데이터베이스를 사용하겠다고 명령문을 주고 테이블을 조회해보면 여러가지 정보들이 나오게 된다.

테이블의 table_name을 조회해보기 위해 select table_name from tables limit 0,1 명령어를 주면 table_name에 테이블이 있다고 표시되게 된다. 그리고 length명령어를 줘서 테이블이름의 길이를 조회해보면 14라는 결과값이 나오게 된다. 악의적인 해커들이 이런식으로 자신이 어느정도의 길이가 되는 정보를 알고싶은지 조회할 때 이런 쿼리를 쓰게 된다. 하나 더 추가로 아래 구문과 같이 = 1이라는 숫자를 붙여줬는데 이게 table_name안에 있는 테이블이 길이가 1이 맞는지 확인해보기 위해서 쓴다. 하지만 결과는 0(거짓)으로 나오게 된다. 

반면에 14라는 값을 주게 되면 1이 출력이 되게 되는데 이것은 참이라는 뜻이다. 아까도 봤지만 길이는 14였기 때문이다.

이제 길이를 알았기 때문에 암호화된 이름을 어떤식으로 푸는지 알아보자.

substr이라는 쿼리문을 썼는데 문자열 시작 위치에서부터 개수만큼의 글자를 가져오는 쿼리문이다. 

substr(문자열, 시작위치, 개수) 이런식으로 쿼리문을 구성해주면 된다. 주로 Blind SQL 인젝션 공격할 때 쓰는 대표적인 쿼리이다. 사진에서 보면 table_name에서 어떤 글자인지 알아보기 위해 조건문을 줬는데 뒤에 1,1이라고 썼는데 첫번째 글자부터 1개를 출력해서 C가 나온 것이고 2,1은 두번째 글자부터 1개를 출력해 H를 출력하는 형식으로 해서 테이블 이름을 알아내는 구조이다.

또 하나의 공격 쿼리가 있는데 참인지 거짓인지 알아보는 형식으로 푸는 쿼리이다.

이런형식으로 아까와 비슷한 쿼리문을 썼지만 맨 뒤에 A,B,C와 같은 문자가 붙었다는 것이 특징이다. 3번째 글자부터 1개를 출력해서 그게 A인지 B인지 C인지 판별해서 맞으면 1 틀리면 0을 출력시켜 테이블 이름을 알아내는 공격 쿼리이다. 이 또한 많이 쓰이고 있는 공격쿼리 중 하나이다.

마지막으로 아스키코드 방식으로 공격하는 쿼리가 있는데 어떤형식인지 알아보자.

이런형식을 띠고 있는데 ascii라는 쿼리문이 추가된 화면이 보일 것이다. 뒤에 65, 66은 아스키코드 번호인데 이런형식으로 참인지 거짓인지 판별해서 아스키코드 값을 해독해내서 알아내는 방식이 있다. 아스키코드를 잘 모른다면 구글에 아스키코드표가 있으니 그걸 참고해보면서 공부하면 될 것 같다.

(2) Blind SQL 인젝션 Boolean-Based 실습

이번에는 비박스를 활용해서 Blind SQL인젝션에 대해 실습해 보려고 한다. Boolean-Based라는 것을 선택하고 핵을 눌러준다.

이게 참인지 거짓인지 확인해보기 위해 'or 1=1 #이라는 명령어를 주고 탐색을 눌러보면 정상적으로 데이터베이스가 있다고 결과가 나오게 된다.(참)

반대로 'or 1=2 #이라는 명령어를 주고 탐색을 누르면 데이터베이스가 존재하지 않는다는 결과가 나오게 된다.(거짓)

이제 movie라는 테이블에서 id=1이고 첫번째 시작글자가 G가 맞는지 확인해보는 실습이다. 'or id=1 and substr(title,1,1) = "G" #이라는 쿼리를 입력하고 탐색을 누르면 결과가 참이라는 화면이 나오게 된다. 이런 기초 실습이 되어 있어야 후에 응용도 할 수 있으니 잘 알아두면 좋다.

반대로 타이틀 뒤에 2라는 것을 넣어주고 G가 맞는지 보면 데이터베이스가 없다고 거짓이 나오게 된다. 실제로 테이블을 확인해봐도 2번째에서 첫번째값은 G가 아님을 확인할 수 있다.

(3) Blind SQL인젝션 (WS/SOAP) 실습

이것도 아까 했던 실습과 큰 차이는 없다. 이번엔 웹페이지 URL을 바꿔서 알아보는 방법인데 이 역시도 title 취약점을 이용해서 해킹해보는 실습이다. 타이틀은 아무거나 주고 뒤에 or 'a'=a라고 입력하면 화면에 100movie~라는게 출력됨을 볼 수 있다. 해커들이 주로 이 방식을 이용해 공격한다.

반면 b라는 값을 넣어주면 화면에서와 같이 movie테이블에서 확인할 수 없다는 거짓판별을 내린다.

(4) sqlmap 테스트 실습

이번에는 sqlmap으로 배너를 알아보기 위한 실습이다. 지난번 포스팅에서도 한번 한거라 크게 어려움은 없을 것이다. 

칼리리눅스를 실행시키고 위와 같은 명령어를 입력해준다. 자신이 사용하고 있는 URL 주소와 프록시를 걸어서 알아낸 쿠키값을 넣어주고 실행시킨다.

그리고 몇분동안 실행이 진행되다 보면 banner가 실행되어 현재 시스템 정보들을 알아낼 수 있다. 지난 포스팅에서도 이야기 했지만 Sleep함수는 절대 함부로 쓰면 안되는 함수이다! 

Blind SQL인젝션 실습에 대해 간단히 포스팅 해봤는데 생각보다 노가다성도 강한 공격이다. 계속 바꿔주고 바꿔주는 형식으로 해서 공격해야 하는 방식이기도 하지만 해커들이 많이 사용하는 공격이기도 하기 때문에 잘 알아두면 대응책을 생각해 볼 수도 있을 것이다. 본인도 계속 알아가는 과정이며 많은 공부를 한다고 생각한다.