4. 데이터 변조 – 세션 변조를 통한 불법 로그인

보안 2010. 11. 23. 18:58

앞의 섹션에서 Paros , 아킬레스 와 같은 프록시 툴에 대해 살펴 보았습니다.

이번에는 웹 해킹 중 세션값을 변조 하여 불법 로그인을 시도하는 것에 대해 알아 봅니다.

 

정상적인 로그인 과정을 거치지 않은 , 권한이 없는 사용자의 불법 로그인은 

데이터 변조 중에서도 아주 파급효과가 큰 보안 위험성을 가진다 할 수 있을 것입니다.

 

이 과정을 살펴 보기 전에 세션에 대해 간략히 살펴 봅니다.

 

* 세션이란

HTTP 프로토콜은 상태가 없는 Stateless 의 특성을 가집니다.

(HTTP 프로토콜 특성은 앞의 섹션에서 다루었습니다. 앞 섹션들을 참고해 주세요)

기본적으로 연결을 유지 않는 HTTP 프로토콜은 유지 시킬 수 있는 방법이 없습니다.

따라서 서버의 입장에서 보면 방금 요청한 클라이언트가 이전에 요청 했던 놈인지

알 방법이 없다는 말이 됩니다.

 

HTTP 프로토콜 특성 상 클라이언트를 식별하는 별다른 방법이 있을 수 없겠지요.

그래서 이전에는 쇼핑몰과 같은 웹사이트에서 장바구니과 같은 특정 클라이언트 종속적인

데이터들은 쿠키에 저장하곤 했습니다.(현재에는 DB 기반으로 많이 바뀌었죠?)

또한 회원 기반의 웹 사이트들은 사용자로 하여금 회원가입을 받고 로그인 이라는 과정을

통해 특정 클라이언트를 식별 하기도 합니다.

 

이 로그인 이라는 과정에서 세션이라는 특수한 쿠기(?)를 사용하게 됩니다.

쿠키란 사용자(클라이언트)의 컴퓨터에 저장되어 웹 서버로 요청 시 마다 HTTP 헤더에

포함되어 전송되는 데이터를 말합니다.

 
아래의 그림은 보통 웹사이트에서 로그인을 처리하는 과정을 시스템 측면을 보여 줍니다 

  
  
  클라이언트는 id pw 를 입력하여 서버로 로그인을 요청합니다.

서버는 유효한 사용자인 경우 서버 자신의 메모리에 유일한 세션 ID 를 저장합니다.

또한 클라이언트에게도 동일한 세션 ID 을 쿠키로 저장합니다.

클라이언트의 다음 요청 시 이 세션ID 가 서버로 전송되며 서버는 저장되어 있던

세션 ID 와 비교하여 해당 클라이언트를 식별합니다.

이렇게 하여 특정 클라이언트의 상태를 알 수 있는 구조 입니다.

결론적으로 세션 역시 쿠키로 저장된다는 것이 중요한 것입니다.

이때 부여되는 세션 ID 는 아래와 같은 형태입니다.

Cookie: ASPSESSIONIDACQCCDRQ=BGALHGKACCDPEHLLCIDEBCFF

또 한번 말씀 드리지만, 세션은 서버와 클라이언트에 동시에 저장되는 쿠키이며

이 쿠키는 변조 될 수 있으며 이는 결국 세션의 변조를 통해 유효한 사용자가

아니라 해도 로그인을 할 수 있게 된다는 결론에 도달합니다.

(물론 간단한 세션 변수만으로 로그인을 처리하는 웹 사이트의 경우에 한합니다

그러나 이 방법은 아직까지 아주 많이 사용되어 지고 있습니다)


아래 그림은 불법 로그인을 시도하는 것을 나타 냅니다. 
  

  

불법 로그인 시도 방법.

1. 유효한 사용자는 정상적인 로그인 과정을 거쳐 서버로부터 세션 ID 를 얻게 된다

2. 악의의 사용자는 이 정보를 가로 챈다

   쿠키값을 가로채는 방법에 대표적으로 XSS 와 같은 공격 유형이 있습니다.

3. 악의의 사용자는 이렇게 가로챈 세션 ID 를 자신의 세션 ID 와 교체하여

   불법으로 로그인을 하게 된다.

   (이 때 세션값을 교체하기 위해 웹 프록시 툴을 사용하게 됩니다)

지금부터 간단한 데모 화면을 통해 위 과정을 살펴 봅니다.


데모를 위해 간단하게 로그인 프로그램을 아래와 같이 작성 합니다.

1. LoginForm.asp

<script language="javascript">

  function logout(){

    location.href = "LogOut.asp";

  }

</script>

<% if Session("MemberID") = "" then %>

<form method="post" action="LoginOK.asp">

  ID : <input type="text" name="id"><br>

  PW : <input type="text" name="pwd"><br>

  <input type="submit" value="로그인">  

</form>

<%

  else

%>

<%=Session("MemberID") %> 님 반갑습니다

 

<form method="post" action="LogOut.asp"> 

  <input type="submit" value="로그아웃"> 

</form>

<% end if %>

2. LogOK.asp

<%

  id = Request("id")

  pwd = Request("pwd")

  Session("MemberID") = id

 

  Response.Redirect "LoginForm.asp"

%>


 
 

1. TEST 라는 사용자는 정상적인 방법으로 로그인을 시도 한다.


   

 

1-1. 아직까지 XSS 와 같은 세션 가로채기는 알아 보지 않았으므로 테스트를 위하여

 웹 프록시 툴을 사용하여 TEST 사용자의 세션 ID 값을 알아 냅니다. 
  
 


(이 세션ID 를 따로 저장 해 두세요)
 
 

3. 이제 새 브라우저를 띄워서 LoginForm.asp 를 호출 합니다.

   새 브라우저 에서 새로 호출된 LoginForm.asp 화면엔 이전과 같이 로그인 폼이

   나타 날 것입니다.

   그러나 우리는 이 새 브라우저가 이미 로그인 한 TEST 라는 사용자로 인식하게

   할 것입니다. 다시 말해 로그인 폼이 뜨지 않도록, 이미 TEST 로 로그인 되도록

   하는 것입니다(바로 불법 로그인이 되겠지요)

   세션 ID 를 교체하기 위해 웹 프록시 툴을 사용하여 요청 중에 세션 ID 값을

   이전에 저장해둔 값(TEST 의 세션 ID)으로 교체 합니다.

 


   

   

  


 

4. 짜짠~~ . 새로운 사용자(브라우저)는 로그인 과정을 거치지도 않았는데

   TEST 로 로그인 했다고 나옵니다. 
  


   

정상적인 경우라면 새 브라우저(새 사용자는) 로그인 폼이 나타나야 되는데

 중간에 세션 쿠키값을 변경함으로써 서버는 이 새로운 사용자를 TEST 로 인식하게

 되는 것입니다.

즉 서버 입장에서는 서버 메모리에 저장되어 있는 세션 ID 값과 클라이언트가 보내 준

세션 ID 값을 비교 하여 사용자를 판단 하기 때문에 이와 같은 결과가 나타나는 것입니다.

다만, 이 세션 값 새 사용자는 TEST 라는 사용자에게 부여된 세션 ID 가 서버에

남아 있을 때 만 유효 합니다.

즉 세션 시간 만료나 사용자가 로그아웃을 해 버린 상태에서는 이 공격은 통하지

않는 다는 말이 됩니다.

그래서 일반적으로 이 공격은 아래와 같이 이루어 집니다.

= 세션 가로채기 및 변조 공격 방법 =

1. 악의의 사용자는 XSS 와 같은 악성 스크립트를 유효한 사용자로 하여금 의도적으로 실행하게 하여 즉시 자신에게로 알리는 미들웨어 같은 놈을 하나 만들어 둡니다.

2. 알림을 받은 악의의 사용자는 제 빨리 해당 사이트로 이동하여 세션 변조를 통해

   로그인을 시도 합니다. (마이페이지 같은 곳이나 로그인 과정 시도)

   (사용자가 로그아웃 하기 전 또는 세션 시간이 만료 되기 전에 제 빨리..)

3. 불법 로그인이 성공하면 이제부터는 정상 사용자의 계정으로 못된 짓을 하겠지요..

그럼.. 대책이 있나요?????

당연히 대책이 있겠지요.. 웹 보안 시리즈를 게재하는 목적이기도 하구요..

아래와 같은 사항들을 점검 하세요..

1. 웹 방화벽 사용  (회사에서 사 주면 -.-)

2. 일부 네트워크 보안 장비에서도 쿠키 값 변조를 감지하는 장비가 있습니다.

   (이것 역시 회사에서 사 주면 -.-;)

3. PKI 솔루션 도입 (또한 회사에서 사주면 -.-)

4. 자체적으로 쿠키 값 변조를 탐지하는 필터 개발

   보편적으로 많이 사용되는 해시 알고리즘을 이용해 구현하시면 됩니다.

   (시간과 능력이 허락하면..)

5. 단순한 세션 변수로만 인증 체크 하지 말 것

   세션이 부여 될 때 사용자의 IP 를 묶어서 저장하고 매 요청시 마다 대조 하도록 합니다.

   (조금 우울한 시나리오 이긴 합니다. 또한 공공 장소에서 사용하는 여러 컴퓨터는 같은 IP 를 공유하는 경우도 있으니 홀(구멍)이 있습니다)

6. 기타 참신한 아이디어 ^^;

 

 
 
*** 경고 경고 경고 경고 경고 경고 경고 ***
위와 같은 웹 해킹 시도는 자신과 관계 없는 사이트에는 하지 않는 것이 좋습니다.
일반적으로 유용한 정보나 서비스를 제공하는 웹 사이트들은 위와 같은 공격에 이미 대응하고 있으며
또한 공격이 통하지 않도록 하는 것은 물론 공격에 대한 로그도 남깁니다.
따라서 언제든 추적 및 책임을 물을 수 있으니 아예 시도 하지 않는 것이 좋습니다.
단지 테스트가 목적이라면 자신이 직접 만든 테스트용 사이트나 아는 분의 사이트에 미리 공지를 하고 해 보시기 바랍니다.



'보안' 카테고리의 다른 글

6. 데이터 변조 – 쿠키 변조  (0) 2010.11.23
5 데이터 변조 – 히든 필드 변조  (0) 2010.11.23
2. SQL INJECTION  (0) 2010.11.23
1. 웹은 보안에 취약하다? 왜???  (0) 2010.11.23
Log Injection  (0) 2010.11.23
: