R4v!dus

유니버설 플러그 & 플레이는 범용 플러그 & 플레인 라고도 한다.

컴퓨터 네트워크 프로토콜의 집합으로 UPnP이라는 용어는 컴퓨터에 직접 장치를 유동적으로 부착하는 기술인 플러그 & 플레이에서 비롯된 것이다.

UPnP는 PC, 무선장비등을 네트워크에 접속시켰을시 서로가 서로를 인식하고 자동으로 인터넷과 웹 프로토콜을 사용하여 연결 해주는 일을 한다.

UPnP를 사용하면 네트워크 접속 환경을 자동으로 구성한다.

ex)

토렌트의 경우 설치시 별도의 포트포워딩 없이 작동이 되는데 이 또한 UPnP를 이용하였기 때문이다.
(설정을 통하여 포트포워딩을 확인할수 있다.)

curl 은 커맨드 라인에서의 데이타 송수신 툴로 HTTP와 HTTPS 를 지원한다.

HTTP 기반의 서비스를 테스트하는 용도로 사용된다.

*http, https 뿐만 아니라  FTP, FTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS, FILE, SSL, HTTP POST, HTTP PUT, FTP uploading, HTTP form기반의 upload, proxies, cookies, user+password 인증도 제공한다.

사용법

curl [-option] [url]

옵션

-d HTTP Post data

-H 헤더 설정, 헤더 정보 전달

-i 헤더값 확인

-k https 사이트를 SSL certificate 검증없이 연결

-l 사이트의 header정보와 body정보 확인

-s 진행 내역이나 메시지 등을 출력 하지 않게 함

-v request, response의 헤더와 바디 확인

다른 플러그인 : https://wappalyzer.com/

SSL을 이용한 통신을 할 때 Server와 Client는 보안 채널을 통해 데이터를 주고 받게 되며 보안 채널을 만들기 위해서 SSL 혹은 TLS가 사용된다.

TCP/IP 구조의 경우 Server와 Client가 직접연결되는 것이 아니기에 중간에 공격자에 의해 데이터가 변조될 가능성이 있다.

Client가 Server와 SSL 통신을 하고 있는 중이라면 공격이 불가능 하겠지만 SSL연결을 요청하는 초기 단계라면 이야기는 달라진다.

SSL MITM Attack

MITM은 공격자가 중간에서 SSL인증서만을 가로채는 공격기법이다. (네 이게 답니다. 이 과정에 전문 지식을 요할 뿐...)

이는 공격자가 사용자에게 서버인척 가짜 인증서를 송신한다.

이를 수신한 사용자는 가짜 인증서에 있는 공개키로 개인정보등을 암호화해서 공격자에게 보내준다.

공격자는 이를 이용해 서버에게서 SSL 인증서를 발급 받는다.

1. 사용자 <-> 공격자 (가짜 인증서를 활용한 정보 탈취)

2. 공격자 <-> 서버 (탈취한 정보를 이용한 SSL 인증) 

HTTPS를 벗겨내는 Strip 공격과는 다른 방식이다.

SSL Strip Attack

Client가 Client Hello Message를 전송 할 때 이를 가로챈 공격자는 자기가 마치 사용자인 것 처럼 Client Hello Message를 Server에게 전달해준다. Server는 Server Hello Message와 서버 인증서를 공격자에게 제공해준다.

이렇게 보안 인증서가 나오기전 사이를 탈취하면서 SSL Strip Attack이 성립된다.

사용사 <--HTTP--> 공격자 <--HTTPS--> 서버 

형식을 띄게 된다.

1. 사용자 --> 공격자 (사용자가 서버에세 SSL 인증서를 발급받기 위한 절차 수행중)

2. 공격자 --> 서버 ( 그 절차 사이에 끼어들어 자기를 거쳐 가게끔 함)

3. 사용자 <-> 공격자 (HTTP로 통신 진행)

4. 공격자 <-> 서버 (HTTPS로 통신 진행)

SSL은 보안 소켓 계층을 이르는 말로 인터넷 상에서 데이터를 안전하게 송수신 하기 위한 암호화 통신 프로토콜입니다.

HTTP는 평문 데이터를 전송하기에 암호화가 필요한 서비스들 이를테면, 사내문서, 전자메일 등에서 사용하기에는 어려움이 있습니다. 이를 해결하기 위해서 SSL layer를 거쳐 HTTPS가 되도록 합니다.

HTTP -> SSL(Layer) -> HTTPS

SSL 동작원리

SSL프로토콜은 응용계층과 전송 계층 사이에 프로토콜 계층을 만들어서 동작합니다.

응용계층의 프로토콜들은 외부로 보내는 데이터를 TCP가 아닌 SSL에 보내고 SSL은 받은 데이터를 암호화하여 TCP를 거쳐 외부로 전달합니다.

SSL Layer는 TCP가 아닌 데이터가 전송될 경우 SSL Layer를 거쳐 TCP로 전달되어 외부로 데이터가 전송됩니다.

해당 데이터를 전달 받을시, 암호화된 데이터를 수신 받게 되는데 이는 수신측  SSL Layer에서 복호화를 통해 데이터 처리가 이루어집니다. 수신할때 TCP로 받은 데이터는 복호화하여 응용계층에 전달됩니다.

Application은 SSL을 TCP로 인식 TCP는 SSL을 Application으로 인식 하기에 기존 전달방식을 그대로 사용합니다.

SSL은 TCP 위에서 Record Protocol을 통해 실질적인 보안서비스를 제공하고, Handshake Protocol, Change Cipher Spec Protocol, Alert Protocol을 통해 SSL 동작에 관한 관리를 합니다.

Handshake Protocol

암호 알고리즘 결정, 키 분배, 서버 및 클라이언트 인증을 수행하기 위해 사용되는 프로토콜입니다.

Record Protocol 

데이터의 압축을 수행하여 안전한 TCP패킷으로 변환시킵니다. 데이터 암호화 및 무결성을 위한 메시지 인증을 수행합니다.

총 5가지 단계를 거칩니다.

Fragmentation : 메시지 즉, 데이터는 작은 블록으로 조각화가 이루어집니다.

Compression : 조각이 된 블록에 대하여 압축이 진행됩니다.

Add MAC : SSL-Handshake 프로토콜에 설정된 비밀키를 사용하여 MAC를 계산합니다.

Encryption : MAC을 포함한 데이터를 SSL-Handshake에 설정된 대칭키를 사용하여 암호화를 진행합니다.

Append header : SSL Header가 암호화된 블록에 추가되며 Header에는 각종 필드가 포함되어 있습니다. 

Change Cipher Spec Protocol

암호화 알고리즘과 보안 정책을 조율하기 위해 사용하는 프로토콜입니다. Handshake 과정에서 데이터 암호화용 대칭키 생성이 완료되고 나면 그 이후부터 데이터를 암호화하라는 신호를 보내는데 사용됩니다.

Alert protocol

Clinet or Server side에 오류가 발생할시 상대방에게 경고 메시지를 보내며 오류가 critical 할시에 SSL 연결을 닫습니다.

Unexpected message : 부적절한 메시지가 수신될 때 발생

Bad record MAC : 잘못된 MAC으로 메시지가 수신될 때 발생합니다.

Handshake failure : 보낸 사람이 옵션에서 허용되는 보안 매개변수 집합을 협상할수 없을시에 발생합니다.

Decompression failure : 압축 해제에 실패할때 발생합니다.

Iligal parameters : Handshake 메시지의 필드가 범위를 벗어날 때 발생합니다.

HTTP Strict Trasport Security는 웹 사이트를 보호하는 웹 보안 정책 매커니즘이다.

지원되는 브라우저가 헤더를 수신하면 해당 브라우저는 HTTP로 통신이 전송되는 것을 방지하고 HTTPS를 통해 모든 통신을 전송 하게 된다.  

HSTS는 다음과 같은 위협을 해결한다.

-사용자 북마크 또는 수동 입력 url 및 중간자 공격 대상

HSTS는 대상 도메인에 대해 HTTP 요청을 HTTPS로 자동 리다이렉션 한다.

-HTTPS로 의도된 웹 응용 프로그램이 HTTP링크 및 HTTP를 통한 컨텐츠를 제공 하는 경우

HSTS는 대상 도메인에 대해 HTTP 요청을 HTTPS로 자동 리디렉션한다.

-MITM (Man-in-the-Middle) 공격자가 잘못된 인증서를 사용하여 대상 사용자의 트래픽을 가로 채려고 시도하고 사용자가 잘못된 인증서를 수락하는 경우

HSTS는 사용자가 유효하지 않은 인증서 메시지를 무시하도록 허용하지 않는다.

취약점

사이트 소유자는 HSTS를 사용하여 쿠키가 없는 사용자를 식별 할 수 있지만 이는 개인 정보 유출로 이어 질 수 있다.

includeSubDomains 옵션을 생략하면 하위도메인에서 쿠키를 조작 할 수 있게 되며 HSTS가 하위 도메인에 유효한 인증서를 요구하여 쿠키 관련 공격이 허용된다.

대응방안

모든 쿠키에  secure 플래그를 설정하면 동일한 공격을 방지 할 수 있다.

브라우저에서 쿠키는 기본적으로 HTTP, HTTPS 프로토콜에 관계없이 서버에 전달된다. 이 경우 HTTP 요청시 외부의 공격자에게 쿠키 정보를 탈취당할 수 있다. secure를 명시하면 HTTPS 프로토콜일 경우에만 쿠키를 전달하여 외부의 공격자로부터 쿠키 정보를 보호할 수 있다.

Set-Cookie: name=value; secure

Cooike 설정에 관한 추가적인 정보는 해당 포스팅을 이용하면 된다.

https://blog.ravidusash.kr/121