Wechall 이라는 워게임 사이트가 있다.

여기서 여러 문제를 해결하면서 실력을 쌓을 수 있다.

오늘 풀이를 할 문제는 Coding 카테고리의 Training이다.



(Training: Programing 1 선택)



초록색으로 표시된 이유는 내가 한번 풀었기 때문에
초록색으로 표시된 것이다.

들어가보면



(문제화면)



문제를 보면 this link를 들어가서 받은 메세지를 다시 보내라는 뜻이다.

일단 this link에 들어가보자



(메세지)



메세지가 보인다.
이 메세지를 다시 보내라는 것이다.
어디로?

아래 드래그한 주소로!


(솔루션 보낼 곳)


뒤에 the_message부분에 우리가 받은 코드를 입력해서 전송하면 된다.

물론 시간제한이 1.337초 이므로 손으로는 불가능하며
네트워크 통신도 원활해야한다...

먼저 파이썬 챌린지에서 했던 urllib.request를 이용해 접근해보겠다.!




(??..)



url로 접속하니 로그인을 한 후
해당 쿠키로 접속을 해달라고 메세지가 왔다.

즉, 그냥 url만 보내면 안되고
접속했을 때의 쿠키값을 HTTP 헤더에 포함시켜서 보내야하는 것이다.!

와이어샤크로 나의 쿠키값을 확인해보겠다.



(쿠키값 확인)



와이어샤크로
나의 쿠키값을 확인 할 수 있다.

이제 이 값을 포함시켜서 url접속할 것이다.



(쿠키 추가)



쿠키를 추가한 모습이다.
그리고 code에 decode하여 우리가 원하는 문자열을 받았다.



(결과화면)



우리가 보내야할 코드가 잘 전달 되었다 :)

이제~ 이 값을 url 뒤에 붙여서 전송할것이다.



(답 전송)



전송 하고나서 수신된 메세지는 텍스트로 오기때문에 읽기가 힘들다...
그래서
와이어샤크로 확인을 해야한다.
와이어샤크로 확인!


(..?)



정답이다! 하지만,, timeout... 1.63초로..
현재 카페에서 하고있어서 빠르지 못했나보다..

다시 여러번의 시도를 한 후에야 통과했다. ( 네트워크가 빠른 곳에서 하는걸 추천한다.)



(정답화면)



나는 이미 한번 풀었기 때문에
이미 풀었던 문제라고 메세지가 돌아왔다.

문제 해결!


'WarGame > WeChall' 카테고리의 다른 글

WeChall - (Training) Prime Factory  (0) 2017.02.13



* HTTP 패킷의 구조에서
Body가 존재하면 헤더에는
content-type
content size 이 반드시 있어야한다.

HTTP 패킷을 전송해볼 것이다.

HTTP는 TCP 위에서 동작하는 것이다.
이 때 좋은 툴이 있다. NetCat이라는 프로그램이다.
이 프로그램은 TCP 통신을 하는 프로그램이다.

* NetCat
 - telnet과 유사한 프로그램
 - TCP 통신을 할 수 있는 프로그램

1. 리눅스용
 - nmap 패키지에 포함
 - ncat
 - 서버로 실행 가능
 - 클라이언트로 실행 가능

2. 윈도우즈용
 - netcat
 - nc.exe
- 내용은 리눅스용과 같다.

NetCat을 설치할 것이다.
리눅스에서 ncat은 nmap 패키지에 포함되어있으므로 nmap을 설치해준다.




(nmap 설치)



ncat의 옵션을 확인해본다.




(ncat 옵션)



ncat으로 10000번 포트를 listen 상태로 열어둔다.




(10000번 포트 개방)



호스트에서 접속을 해볼 것이다.
윈도우에서는 nc.exe로 실행한다. 뒤에 IP주소와 포트번호를 적어주면 연결이된다.



(연결된 모습)



(리눅스 모습)


텍스트를 주고받을 수 있는 모습을 볼 수 있다.

netcat으로 http 통신을 확인해볼 것이다.
* 네이버에 페이지 요청을 하는 request패킷을 전송해볼것이다!

netcat을 이용해서 아래의 패킷을 보낼것이다. \r\n   캐리지리턴이 꼭 들어가야한다.
한줄 띤것까지 복사해서 보내본다.
-----------------------
GET / HTTP/1.1
Host: www.naver.com

-----------------------



(naver.com 연결)




(http 응답)



http의 웹 코드를 받은 것을 확인할 수 있다.

이제부터 실습을 naver.com에 직접하기는 조금 그러니
http 웹 서버를 리눅스에서 설치해서 그 페이지를 대상으로 패킷을 주고받아 볼 것이다.

리눅스에서 httpd를 설치한다.



(httpd 설치된 모습)



설치된 httpd에서 기본 설정된 페이지는 /var/www/html  에 들어있다.
여기에 기본 페이지 index.html을 만들어줄것이다.



(기본페이지 경로)




(간단한 페이지 작성)



페이지까지 작성을 했으면
웹서버를 실행시켜준다.




(웹서버 실행)



이제 호스트에서 인터넷 브라우저로 접속해본다.




(실험 타겟 페이지)



페이지가 잘 나온 것을 확인할 수 있다.

ncat을 이용해서 아까와 똑같이 get요청을 하여
응답을 받아봤다. 



(응답 모습)





(와이어샤크 분석)



와이어 샤크로 본 모습도 추가했다. 위와같은 메세지를 주고받은 것을 확인 할 수 있다.


여기서 헤더에 구성을 살펴보면 헤더를 이용한 취약점을 발견할 수 있다.

* DDos
 - GET Flooding : 대량의 GET패킷을 보낸다. 서버의 부하를 높인다.
 - CC Attack
   ( CC : Cache Control )
 - GET Flooding은 CC Attack과 함께 같이 사용한다.
 헤더의 Cache-Control에 no cache 등으로 설정해서
 캐시를 쓰지 않겠다해서 서버에 부하를 더 높이기 위한 방법이다.
 

 - Slow attack
1) slowloris attack
 
 - 헤더의 끝을 포함하지 않은 상태로 요청
 - 서버에서는 헤더가 완전히 도착하지 않았다고
    간주하여 세션을 계속 열어둔 상태로 둔다.

2) slow read attack
 -> body가 있어야하기 때문에 GET으로는 못한다.
 - 메세지 Body를 이용한다.

slowloris 공격과 slow read 공격을 직접 해보겠다.

1) slowloris 공격
이 공격은 마지막 캐리지 리턴을 빼서 보내는 것이다. 그렇게 되면
서버는 아직 패킷이 다 오지 않은줄 알고 다음 패킷을 계속 기다린다.
원래 웹서버는 통신이 끝난후 바로 연결을 끊는다.(사용자가 많기 때문에)
하지만 이렇게 계속 열어두게 되면
이런 패킷들이 많다면? -> 서버는 다운될 수 밖에 없다.

파이썬으로 프로그램을 작성했다.



(slowloris 공격 코드)



코드를 보면 50초마다 fake 헤더를 보내주는데
이유는 웹서버가 기다리다가 끊으려고 할 때쯤
헤더인것처럼 하나 더 보내주면 서버는 ' 아! 아직 더 있었구나!' 하고 기다린다.
그러다 또 끊으려고 하다가 또! 아! 더있구나! 하고 이런식으로 계속 기다리게 하는것이다.

와이어샤크로 분석해보았다.




(디도스 공격 패킷)




(웹 서버 포트 창)



웹서버의 포트 상태를 확인하면 ESTABLISHED로 되어있다.
웹서버에서는 이 상태는 비정상적인 것이다. 왜냐하면 웹서버에서는 통신을 하고 바로 끊기 때문이다.
이런 상태로 계속, 여러개 수가 많아지면 웹서버는 부하가 엄청날 것이다.

2) slow read 공격
content-length 헤더를 엄청 크게 잡아준다.
그리고 body의 내용을 찔끔찔끔 보내주는 것이다.
그러면 웹서버의 입장에서는 계속 기다려줘야하는 상황이 발생한다.
이런 패킷들이 많다면
웹 서버는 다운되게 된다.
body를 포함해야하므로 post 메소드를 이용해 패킷을 전송한다.




(slow read 공격 코드)




(패킷 상태)





(공격받은 모습)



이 공격도 마찬가지로 established가 되어있음을 확인 할 수 있다.




* HTTP ( Hyper Text Transfer Protocol )
 - 웹(Web) 통신에서 사용되는 프로토콜

* HTTP 메세지 구조
(\ -> 역슬래쉬)

-기본
start line\r\n   (모든 메세지는 스타트라인 한줄을 가지고 있다.)
header-field\r\n (헤더필드는 여러개가 올 수 있다.)
header-field2\r\n
ex)
header-name: header-value\r\n
...
\r\n     (캐리지리턴이 나오면 헤더필더가 다 나왔다는 것이다.
message-body (있을 수도 있고 없을 수도 있다.)

1) HTTP request Message
 request line\r\n
 request-header\r\n
 ...
 \r\n
 message-body







(요청 request-line)



1.1) request-line  ( sp :스페이스(공백), 구분자 )
 
 method sp URI(URL) sp HTTP version\r\n
method 필드




(메소드)



(메소드)



URI Vs URL
- URI : Uniformed Resource Identifier (자원에 대한 식별자)
- URL : Uniformed Resource Location (자원에대한 위치)
         : 어떠한 경로에 있는지 정확하게 나와있다.

2) HTTP response Message
 status line\r\n
 response-header\r\n
 ...
 \r\n
 message-body

2.1) status-line ( sp :스페이스(공백), 구분자 )
 HTTP version (sp) status code (sp) reason phrase\r\n

- HTTP의 request-line과 status-line의 구조를 살펴보았다.


+ Recent posts