구현단계 보안약점 제거 기준-부적절한 인증서 유효성 검증

작성일: 230704

 

※ 본 게시글은 학습 목적으로 행정안전부·KISA의 소프트웨어 보안약점 진단 가이드, 소프트웨어 개발보안 가이드를 참고하여 작성하였습니다.

 

정리 내용: 소프트웨어 보안약점 진단 가이드(379~381p)

구분	- 보안기능
설계단계	- 인증 대상 및 방식 https://cryptocurrencyclub.tistory.com/100
개요	인증서를 확인하지 않거나 인증서 확인 절차를 적절하게 수행하지 않아, 악의적인 호스트에 연결되거나 신뢰할 수 없는 호스트에서 생성된 데이터를 수신하게 되는 보안약점이다.
진단 세부사항 (설계단계)	① 중요기능이나 리소스에 대해서는 인증 후 사용 정책이 적용되어야 한다. 중요기능은 안전한 인증방식을 사용하여 인증 후 사용하도록 설계하고 인증이 수행되도록 설계되어 있는지 확인한다.   ㅇ  중요기능과 중요 리소스에 대한 접근 권한이 분류되어 있는지 확인   ㅇ  접근권한을 기반으로 인증이 요구되는 중요 기능이나 리소스가 분류되어 있는지 확인   ㅇ  인증 누락이 발생하지 않도록 인증적용 방법이 안전하게 설계됐는지 확인(프레임워크 컴포넌트를 활용 및 적용, 인증 누락이 발생하지 않도록 설정)   ㅇ  중요 기능, 리소스에 대한 접근통제가 수행되고 있는지 점검하기 위한 테스트 계획 수립 여부 확인    ② 안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다. 안전한 인증방식을 사용하여 인증 후 사용하도록 설계되어 있는지 확인한다.   ㅇ  인증기능 설계 시 안전한 인증방식을 사용하도록 설계되어 있는지 확인(Type1/ Type2 / Type3)   ㅇ  인증정보의 저장방식이 안전하게 설계되어 있는지 확인(인증 사용값은 안전하게 암호화되어 서버에 저장되어야 함)   ㅇ  인증에 대한 인증횟수 제한 및 오류처리기능의 설계 여부 확인   ㅇ  인증오류 또는 인증실패에 대한 로깅의 설계 여부 확인(인증시도를 추적할 수 있는 인증시도시간/IP/ID정보 등 포함 여부 확인)    ③ 중요기능에 대해 2단계(2-factor)인증을 고려해야 한다. 중요기능은 안전한 인증방식을 사용하여 인증 후 사용하도록 설계하고 2단계 인증 등 보안을 강화하는 방법을 고려해야 한다.   ㅇ  개인정보변경, 비밀번호 재설정, 권한 관리, 관리자 기능과 같은 중요기능의 경우 추가인증을 요청하도록 설계되었는지 확인   ㅇ  추가 인증기능 설계시 안전한 인증방식이 사용되도록 설계되어 있는지 확인   →  ID/PW 또는 OTP, 멀티디바이스를 이용한 추가 인증, (공인/사설) 인증서, 바이오정보(지문, 홍채 등)   ㅇ  추가인증이 요구되는 중요기능을 사용하거나 해당 인증을 실패하는 경우 사용시간, IP주소, ID정보, 사용기능 등이 로깅되도록 설계되었는지 확인
보안대책 (구현단계)	쿠키의 만료시간은 세션이 지속되는 시간을 고려하여 최소한으로 설정하고 영속적인 쿠키에는 사용자 권한 등급, 세션ID 등 중요정보가 포함되지 않도록 한다. 인증서를 사용하기 전에 인증서의 유효성을 확인한다. 인증서의 Common Name과 실제 호스트가 일치하는지, 신뢰된 발급기관(CA, RootCA)의 서명 여부, 인증서의 유효기간, 인증서의 해지여부, 안전한 암호화 알고리즘 사용 여부 확인 등으로 유효한 인증서인지 검증하는 절차를 구현하여야 한다.
진단방법 (구현단계)	① 인증서를 확인하여, ② 검증결과 값이 X509_V_OK 이외의 값을 허용하는지 확인한다. ③ 신뢰되지 않은 발급기관으로 받은 인증서를 허용하거나 유효기간이 만료된 인증서를 허용하면 위험하다. 또한 인증서의 Common Name 확인한다.

 

다. 코드예제

 

ㅇ 분석

1:if ((cert = SSL_get_peer_certificate(ssl)) && host)
2:foo=SSL_get_verify_result(ssl);
3:if ((X509_V_OK==foo) ||X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo))
// 자체 서명된 인증서일 수 있다.

1:cert = SSL_get_peer_certificate(ssl);
2:if (cert && (SSL_get_verify_result(ssl)==X509_V_OK)) {
3:/* CN 을 확인하지 않았지만 신뢰하고 진행한다. 이럴 경우, 공격자가 Common Name을
www.attack.com으로 설정하여 중간자 공격에 사용할 경우 데이터가 중간에서 복호화 되고 있음을
탐지하지 못한다. */
4: }

ㅇ 내용

1. 첫 케이스는 SELF_SIGNED로 자체 서명 인증서로 신뢰성을 담보할 수 없음

2. 두번째는 CN과 호스트의 일치여부를 확인하지 않음

 

ㅇ 수정

1:private boolean verifySignature(X509Certificate toVerify, X509Certificate signingCert) {
2: /* 검증하려는 호스트 인증서(toVerify)와 CA인증서(signing Cert)의 DN(Distinguished
Name)이 일치하는지 여부를 확인한다.*/
3: if (!toVerify.getIssuerDN().equals(signingCert.getSubjectDN())) return false;
4: try {
5: // 호스트 인증서가 CA인증서로 서명 되었는지 확인한다.
6: toVerify.verify(signingCert.getPublicKey());
7: // 호스트 인증서가 유효기간이 만료되었는지 확인한다.
8: toVerify.checkValidity();
9: return true;
10: } catch (GeneralSecurityException verifyFailed) {
11: return false;
12: }
13:}

ㅇ 내용

1. 호스트와 CA인증서의 DN 일치 여부 확인(DN=인증서 주체, 발급자 정보 포함, CN= 인증서 주체)

2. CA 서명정보 확인

3.유효기간 확인

 

 

끝.