'분류 전체보기'에 해당되는 글 438건

금융보안원에서 2018년 8월, 2030년까지 안전성을 허용했던 TDES의 사용을 점진적으로 중지하도록 권고하는 문서가 공개되었다.

여기서 TDES는 Triple Data Encryption Standard의 줄임말로써 3DES라고도 불린다.

보통 컨설팅 시 데이터 암호화에 권고하는 암호알고리즘으로 TDES를 포함하는데 이제는 제외하여야겠다.

자세한 사항은 아래 금융보안원의 문서를 참고하길 바란다.

☞ 다운로드 링크 : http://www.fsec.or.kr/common/proc/fsec/bbs/42/fileDownLoad/1605.do

SSLv3이 취약한 HTTPS 프로토콜이라고 하여 어떤 취약점이 존재하는지 알아본 결과 POODLE 취약점(CVE-2014-3566)이 존재하여 취약하다고 하고 있다.

그래서 POODLE 취약점이 무엇인지, 어떤 식으로 동작하는지를 알아보았다.

1. POODLE이란 무엇인가?

 : POODLE은 Padding Oracle On Downgraded Legacy Encryption의 약자이다.

이를 해석하면 다운그레이드된 구식 암호화에 대한 패딩 오라클이라고 할 수 있다. 그렇다면 다운그레이드가 된다는 것은 무엇이며, 패딩 오라클이란 무엇인가에 대한 궁금점이 생긴다.

2. 다운그레이드의 의미와 POODLE 취약점 효과

 이에 대해서는 먼저 아래의 이미지를 보고 가자.

 SSL과 TLS는 서버와 클라이언트 중 한쪽이라도 최신 버전을 호환하지 않는 경우 이전 버전의 프로토콜로 연결을 재시도하는 동작이 있다.

 위의 이미지를 보면 Client에서 Browser를 이용하여 Server쪽으로 최신 버전의 암호화인 TLS를 이용하여 요청을 보내는데 이 때 공격자가 일부러 TLS에 대한 연결을 끊어 SSL 3.0까지 다운그레이드를 시킨다. 이 후 공격자는 패딩을 이용한 공격을 실행하여 Web 서버와 클라이언트 간의 통신을 Sniffing 할 수 있다.

3. Padding Oracle

 패딩 오라클에 대해서는 간단히 하나의 포스팅으로 넘어가기엔 방대한 설명이 필요하여 간단히만 설명하도록 하겠다.

 패딩 오라클이란 [복호화 시스템에 암호문을 넣었을 때 그에 대한 패딩의 올바름 유무를 보여주는 오라클]이라고 할 수 있다. 이 때, 바로 이 패딩이 올바른지에 따른 서버측의 응답을 이용해 암호화된 값을 평문으로 복호화할 수 있는 취약점이라고 할 수 있다.

부르트포싱을 통한 공격이라고는 하나 현재 Padding Oracle 공격을 위한 툴(https://github.com/iagox86/Poracle)도 존재할 뿐더러, 실제로 암호화된 값이 복호화가 되어 값 변경까지 가능하게 된다면 보안상 큰 구멍이 될 가능성이 존재하므로 많은 고객들을 관리하는 기업에서는 SSLv3가 아닌 TLS만을 사용할 것을 권고한다.

4. 대응방안

 대응방안이라고 하면 말그대로 보안상 취약한 SSLv3를 사용하지 않고 최신의 암호화 기법인 TLS(Transport Layer Security)를 이용할 것을 권고한다.

 아래는 서버 별 설정 정보이다.

참고)

- https://blog.trendmicro.com/trendlabs-security-intelligence/poodle-vulnerability-puts-online-transactions-at-risk/

- https://www.opentext.com/file_source/OpenText/en_US/PDF/OpenText-POODLE-Vulnerability-FAQ-KO.pdf

- https://www.hahwul.com/2015/10/exploit-sslv3-poodle-attack-check-and.html

- http://bperhaps.tistory.com/attachment/cfile30.uf@21B98D33597949BB36C50B.pdf

웹 진단 시 Burp 인증서를 [신뢰할 수 있는 루트 인증 기관]으로 보통 등록을 한다.

그리고 크롬으로 진단을 시작하려고 하면 가끔 아래와 같은 에러를 마주칠 때가 있다.

해당 에러를 읽어보면 웹 사이트가 HSTS를 사용하고 있기 때문에 지금 당장 해당 사이트에 접근할 수가 없다고 한다.

HSTS가 무엇이고 정확히 어떻게 동작하는 것이며, 이걸을 해결하기 위한 정확한 방법은 어떤 것인지 추후 추가하기로 하고 일단 임시방편을 공유한다.

그롬에서 아래의 URL로 접근한다.

그 후 아래와 같이 Query HSTS/PKP domain 이라고 되어 있는 곳의 Domain 부분에 원하는 HOST명을 입력 후 Query 버튼을 누르면 Found라고 뜨면 HSTS가 적용되어 있는 도메인인 것이다.

이 때 가장 아래에 있는 Delete domain security policies 부분에 진단하고자 하는 Domain을 입력 후 Delete를 눌러준다.

그리고 다시 Query HSTS/PKP domain 부분에 domain을 넣고 Query를 눌러보면 Not Found라고 뜬다면 HSTS 적용이 풀린 것이라고 볼 수 있다.

이는 브라우저단에서 처리한 것이기 때문에 임시방편이며, 모든 Domain에 적용되지 않는 것으로 보인다.

( 구글과 페이스북은 테스트 결과 HSTS 적용이 풀리지 않는 것으로 보였다. )

서버측 변경과 HTTP HEADER값 변경 등 여러 방법이 있는데, 서버측에서 변경하는 것은 진단자가 할 수 있는 방법이 아니므로, 추후 HSTS에 대해 조금 더 조사한 뒤 HTTP HEADER값을 이용하는 방법에 대해서도 추가하도록 하겠다.