중요정보 변경 및 초기화, 상품가격조작

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

<실제 사례>

<사진출저: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라는 검증절차를 거치고 보내주겠다는 의미로 해석된다.