CSRF 마무리 / DDoS [13주차]
이번에는 지난 시간에 이어 CSRF에 대해 정리를 하고 나서
현재 인터넷 방송계에서 피해가 엄청나다고 하여 노말틱님이 방송까지 한 것으로 알고 있는!!
현 시점에서 가장 대두되는 문제인 DDOS에 대해 알아보겠다.
CSRF 정의
사이트 간 요청 위조, 사용자가 의도치 않은 요청을 보내는 공격, CSRF를 나타내는 수식어들이 많이 있지만 정의를 꼽으라면 이렇게 말할 수 있겠다.
피해자가 서버로 임의의 요청을 보내게 만드는 공격
확실하게 외워두고 개념을 정리해서 면접 때 잘 대답할 수 있도록 하자.
CSRF vs XSS
CSRF는 위에서 정리한 정의대로 임의의 요청을 보내게 하는 공격이고, XSS는 피해자 브라우저에서 임의의 스크립트가 실행되게 하는 공격이다. 둘 다 클라이언트 측에서 사용자가 피해를 입는 것은 공통적이지만 공격 방식에서 차이가 있다.
그 외에 CSRF와 XSS의 차이점은 아래 이미지를 참고해도 좋다.
CSRF 공격 시나리오
- 중요한 요청을 식별한다.
- 예를 들면 비밀번호 변경이나 2차 인증 관련 혹은 은행업무처럼 돈에 관련된 것들은 많은 피해를 입을 수 있다.
- 해당 요청을 만들 수 있는지 체크한다.
- Burp Suite을 통해 그 요청을 가지고 임의로 보낼 수 있는지를 확인한다.
여기까지만 확인이 된다하더라도 CSRF 취약점이 존재하는 것이다.
CSRF 공격 (GET)
CSRF 취약점이 존재한다?
그러면 먼저 GET method로 link를 생성해서 공격한다.
https://192.168.50.144/vulnerabilities/csrf/?password_new=1234&password_conf=1234&Change=Change
이 공격을 방어하려면 어떻게 해야할까?
POST method의 요청만을 받도록 하면 된다.
CSRF 공격 (POST)
GET method가 막혀서 POST method를 사용할 수 밖에 없다.
그렇다면 POST method로 공격하면 된다. 그러기 위해서는 먼저 XSS 취약점을 찾아야 한다. 그리고는 form tag로 요청을 보내는 스크립트를 작성한다. 마지막으로 클릭을 유도하면 된다. (자동으로 보내게 하는 방법도 있다.)
<h1>아래 버튼을 클릭해주세요!</h1>
<form method="POST" action="https://vuln-site">
<input type="hidden" name="password" value="1234">
<input type="submit" value="Click Me">
</form>
POST method의 공격까지 막으려면 어떻게 해야 할까?
공격자가 요청을 의도한대로 세팅할 수 있는 것이 문제다.
미리 준비할 수 없는 값을 추가하자!! --> CSRF Token
CSRF 공격 (Bypass CSRF Token)
사용자가 로그인할 때마다 임의의 값을 부여하는 CSRF Token은 외부에서 알아낼 수 없다. 하지만 우회하는 방법이 존재한다. iframe으로 CSRF Token 값이 존재하는 페이지를 불러와서 추출하면 된다. 사용자가 접근하는 것이라 사용자의 Token 값이 추출된다.
<iframe sandbox="allow-scripts allow-forms allow-pointer-lock allow-same-origin" width="0" height="0" border="0" style="display:none" name="myFrame" id="if"></iframe>
<form id="form1" action="csrf취약페이지" method="post" enctype="multipart/form-data" target="myFrame">
<input type="hidden" name="pw" value="1234">
<input id="token" type="hidden" name="csrf_token" value="" />
</form>
<script type="text/javascript">
function f1(){
x1=document.getElementById("i1");
x1d=(x1.contentWindow||x1.contentDocument);
//csrf토큰 정보를 가진 dom
t=x1d.document.getElementsByName("csrf_token")[0].value;
document.getElementById("token").value=t;
document.getElementById("form1").submit();
}
</script>
<iframe id="i1" style="display:none" src="csrf토큰이 존재하는 페이지" onload="javascript:f1();"></iframe>
토큰도 소용이 없다. 어떻게 막아야 할까?
이 요청이 어디서 왔는지를 살펴보자. 지금 XSS 취약점이 존재하는 페이지에서 이 요청이 발생하고 있다. XSS 취약점이 존재한다고 하면 게시판 페이지에서도 비밀번호 변경 요청이 발생할 수 있다는 뜻이다. 이것은 문제가 있다.
그래서 CSRF 위험이 있는 요청은 특정 페이지에서만 보낸 요청만 받아들일 수 있도록 하면 된다.
CSRF 공격 (Bypass Referer)
방금 언급했던 특정 페이지에서만 보낸 요청을 받아들일 수 있도록 하는 것이 HTTP protocol의 header 중 Referer 값이다. 이 값은 현재 페이지가 어떤 페이지에서 온 요청인지를 알려준다. 이 Referer 값을 참고하여 특정 페이지에서 온 요청이 아니면 차단하는 방식으로 CSRF 공격을 방어하면 된다.
그렇다면 referer를 우회하여 공격하는 방법은 없을까?
없다!!
Referer는 위조할 수 없기에 제대로 체크한다면 이것을 뚫고 CSRF 공격을 할 수단은 없다.
다만 "잘못된 예외 처리" 라는 것이 존재한다.
만약에 비밀번호 변경 요청을 마이페이지에서만 보낸 것만 인정하도록 했다고 가정해보자. 그렇다면 그 많은 페이지 중에서 마이페이지 외에 정상적으로 비밀번호 변경 요청을 하는 페이지는 존재하지 않을까? 비밀번호 요청이 아닌 다른 요청들은 어떨까?
확신할 수 없다.
개발자들은 그 모든 페이지의 상호관계를 파악하면서 무작정 Referer로 차단할 수는 없다. 자신이 설정한 값으로 인해 정상적인 사용자의 가용성 침해를 할 수 있기 때문이다. 그래서 Referer 값으로 페이지를 특정하긴 하지만 혹시나 있을 다른 곳에서의 요청 또한 허용하는 경우가 있다. 이렇게 에러가 발생할 수 있을 경우, 정상적인 동작을 수행하기 위해 개발하는 것을 잘못된 예외 처리라고 한다.
위와 같은 맥락으로 Referer를 우회할 수 있는 방법이 있다. 바로 Referer 자체를 제거하는 것이다.
<meta name="referrer" content="no-referrer">
CSRF 공격할 때 위의 스크립트를 같이 삽입하면 요청에 Referer가 사라지게 되는데, 이 때 Referer 체크를 안하고 넘어가는 경우가 상당히 많다고 한다.
근본적인 대응 방법
사실 대응 방법은 매우 간단하다. 인증정보, 즉 공격자가 알 수 없는 그리고 알아낼 수 없는 정보를 포함하면 된다. 우리도 이미 잘 알고 있듯이 비밀번호 변경을 할 때, 현재 비밀번호를 입력하게 하는 것이 그러한 방법이다. 이외에도 인증정보는 2차 비밀번호도 될 수 있고, OTP 번호나 지문도 될 수 있다.
디도스(DDoS)
사람들이 흔히들 디도스라고 통칭하여 부르긴 하지만 정확히 도스와 디도스는 다른 말이고 디도스에 대해 알기 위해서는 도스를 먼저 알아야 한다.
도스(DoS)
Denial of Service, 번역하면 "서비스 거부 공격"이란 뜻이다. 도스는 여러가지 전략을 통해 정상적인 서비스를 못하게 하는 공격들을 통칭하는 말이다.
도스 3가지 전략
- 애플리케이션 취약점을 이용
- 이 전략은 어떤 방법을 사용하든 사용자가 해당 서비스를 못 쓰게 하는 방법이다.
- 서버 구동 프로그램인 아파치의 취약점을 찾아 종료시키는 것
- 다른 사람들의 계정을 삭제할 수 있는 취약점을 이용해 계정을 생성할 때마다 삭제하는 것
- 비밀번호 오류 횟수 제한을 이용해 비밀번호를 계속 틀려서 못 이용하게 하는 것
- 이 전략은 어떤 방법을 사용하든 사용자가 해당 서비스를 못 쓰게 하는 방법이다.
- 서버 리소스 소모
- 게시판처럼 서버의 자원을 사용하는 부분에서 자원을 대량으로 소모시키는 방법이다. 자료실같은 부분에 10TB 정도의 파일을 올리면 서버에 부하가 생겨서 정상적인 서비스를 방해하는 방식이다.
- 네트워크 대역폭 소모
- 상대 IP에 대량의 트래픽을 보내 정상적인 요청을 처리할 수 없게끔 하는 방법이다.
- 위의 1,2 방법과는 다르게 서버의 취약점과 상관없이 공격 가능한 방법이다.
디도스(DDoS)
디도스는 Distributed DoS로 도스 공격을 여러 컴퓨터에서 분산시켜 공격하는 방법이다. 요새 도스와 디도스를 구분하지 않고 디도스라고 통칭하는 게 개인PC의 성능도 좋아지고 네트워크 대역폭도 늘어나서 한 대의 컴퓨터로는 치명적인 공격을 할 수 없기 때문이다.
C&C Server (C2 Server)
풀네임은 Command and Control Server로, 악성코드로 인해 감염된 좀비 PC들을 가지고 원격으로 디도스 공격을 수행하게 할 수 있는 서버를 의미한다.
DRDoS(Distributed Reflect DoS)
디도스에서 더 진화된 공격으로 일반적으로 서버에 요청을 했을 때 돌아오는 응답을 이용하는 공격이다. 출발지의 IP를 피해자의 IP로 속여 피해자의 컴퓨터에 대량의 응답 패킷을 보내 네트워크에 부하를 주는 방식이다.
TCP / UDP
디도스에 대해 자세히 알기 위해선 이 부분에 대해 알아야 할 필요가 있다. TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)는 간단하게 인터넷 상에서 데이터를 전달하기 위한 규칙이라고 보면 된다.
TCP(Transmission Control Protocol)
TCP는 IP를 통해 전달된 데이터들이 무사히 도착했는지 확인하는 전송 제어 프로토콜이다. 데이터가 유실되거나 값이 변조된 경우에는 다시 전달하도록 하여 데이터가 무사히 도착할 수 있게 하는 신뢰성 높은 프로토콜이다.
TCP는 안전한 데이터 전달을 위해 출발지와 도착지 사이에 먼저 연결을 시도하고 그 연결된 경로만을 이용하여 데이터를 교환하는데 이 연결하는 과정을 3 Way Handshake 한다. 클라이언트 측에서 먼저 연결을 시도하는 SYN 패킷을 보내면 서버 측에서 그에 대한 답장과 다시 한번 더 확인을 요구하는 SYN/ACK 패킷을 보내고 클라이언트가 마지막으로 확인하는 ACK 패킷을 보냄으로 연결이 완료되고 이후에 데이터 교환이 시작된다.
UDP(User Datagram Protocol)
UDP는 연결따위하지 않는다. 데이터가 도달하는 순서, 데이터 변조나 유실 등등 신경쓰지 않고 그냥 목적지에 데이터를 보내는 프로토콜이다. 기본적으로 TCP보다 속도가 빠르고 간단한 프로토콜이라 최근에는 UDP 위에 새로운 프로토콜을 만들어서 사용하는 경우가 많다.
SYN Flood
TCP 기반의 프로토콜에서 3 Way Handshake 과정을 이용하는 공격 방법이다. 피해자 측 IP에 SYN 패킷만 보내면서 돌아오는 패킷에 반응하지 않으면 피해자 측에서는 계속해서 ACK 패킷을 받기 위해 대기하면서 리소스를 소모하게 되는 방식의 공격이다.
IP Spoofing
spoofing이란 단어가 속이다라는 뜻을 가지고 있듯이 IP Spoofing은 공격자가 자신의 IP를 피해자의 IP라고 속여서 요청을 보내는 공격이다. SYN Flood와 같이 요청을 보내고 돌아오는 응답 패킷을 이용하는 공격으로 여러 웹사이트에 속인 IP로 요청을 하면 모두 피해자 IP로 응답이 돌아가게 되어 네트워크에 부하를 주는 공격이다.
참조
CSRF vs. XSS
Trust is the foundation of any successful business. Unfortunately, it's also a tempting target for attackers. Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS) are two popular and sneaky tactics attackers use to exploit customers' trust by h
www.openappsec.io
Securing CSRF using referer policy
Do you have Cookies?
medium.com
Introductory Guide to Tuning Your TCP and UDP Performance
There are some basic considerations and best practices for tuning TCP and UDP performance. Buffer and write sizes can have a dramatic impact.
subspace.com