A2) Cryptographic Failures

Overview

기존에 민감한 데이터 노출(Sensitive Data Exposure)로 알려졌던 항목이 2위로 한 단계 상승했다. 이 취약점은 근본적인 문제라기보다는 광범위한 증상으로, 암호화 관련된 오류 혹은 부족에 초점을 맞추고 있다. 이러한 암호화의 오류나 부족은 종종 민감한 데이터의 노출로 이어진다.

대표적인 CWE는 다음과 같다:

• CWE-259: 하드코딩된 비밀번호의 사용 (Use of Hard-coded Password)
• CWE-327: 깨졌거나 위험한 암호화 알고리즘 사용 (Broken or Risky Crypto Algorithm)
• CWE-331: 불충분한 엔트로피 (Insufficient Entropy)

 

Description

가장 먼저 해야할 일은 전송 중이거나 사용하지 않고 있는 데이터의 보호 여부를 결정하는 것이다. 예를 들어 비밀번호, 신용카드 번호, 건강 기록, 개인 정보 그리고 기업 기밀들은 추가적인 보호가 필요하다. 이러한 데이터들은 EU의 GDPR같이 개인정보 관련 법률이나, 금융 데이터 보호를 위한 PCI DSS 등의 규제의 적용 대상이 되는 경우가 일반적이다.

이러한 데이터들이 확인해봐야 하는 것들은 다음과 같다.

• 데이터가 평문으로 전송되고 있는가? HTTP, SMTP, FTP같은 프로토콜을 사용하는 경우 TLS를 사용하는 STARTTLS. 외부 인터넷은 굉장히 위험하며 내부 통신(로드 밸런서, 웹 서버, 백 엔드 시스템 간 통신)도 검증해야 한다.
• 오래된 코드에서 기본적으로 오래됬거나 취약한 암호 알고리즘이나 프로토콜을 사용하고 있지는 않은가?
• 기본 암호 키를 사용하거나 약한 암호키를 생성하거나 재사용한다거나 적절한 암호키 관리나 순환이 누락된 것이 아닌가? 암호화 키가 소스 코드 저장소에 기록되어 있지는 않은가?
• 암호화가 강제되고 있지 않는가? 예를 들어서 HTTP 헤더에 보안 헤더가 누락되어 있지는 않은가?
• 서버로부터 받은 인증서와 신뢰 체인을 올바르게 검증하고 있는가?
• 초기 벡터가 무시되거나 재사용되거나 암호학적으로 충분히 안전하게 생성되지 않고 있는가? ECB 처럼 취약한 모드를 사용하고 있지는 않은가? 인증된 암호화가 더 적절함에도 일반 암호화만 하고 있는가?
• PBKDF가 없어서 패스워드를 암호키로 사용되고 있지는 않은가?
• 암호화를 목적으로 하는 난수 생성기가 사실은 암호학적 요구를 만족시키지 못하는 일반 난수 생성기는 아닌가? 만약 올바른 함수를 골랐더라도 개발자가 seed를 설정해야 하는 것은 아닌지, 그렇지 않다면 개발자가 내장된 강력한 시드를 충분한 엔트로피나 예측 불가능성이 부족한 다른 취약한 시드로 덮어쓴 것은 아닌가?
• 더 이상 사용되지 않는 MD5나 SHA1 같은 해시 함수를 사용하거나 해시 함수를 사용해야 하는 경우에 암호화를 수행하지 않는 일반 해시 함수를 사용하는 것은 아닌가?
• RSAES-PKCS1-v1_5 처럼 더 이상 사용되지 않는 암호 패딩 방법을 사용하고 있진 않은가?
• 패딩 오라클 공격 등의 암호화 에러 메시지나 사이드 채널 정보가 유출되어 악용될 가능성은 없는가?

 

How to Prevent

최소한으로 수행해야 될 사항들

• 애플리케이션이 처리, 저장, 전송하는 데이터를 분류해야 한다. 어떤 데이터가 개인정보 관련 법률, 규제 요구사항이나 비즈니스에 따라 민감한지 분류한다.
• 민감한 데이터는 불필요하게 저장하지 말아야 한다. 최대한 빠르게 폐기하거나 PCI DSS로 토큰화하거나 데이터를 잘라서 보관해라. 보관하지 않는 데이터는 탈취당할 수 없다.
• 모든 민감한 데이터는 반드시 암호화해야 한다.
• 최신의 강력한 표준 알고리즘과 프로토콜 그리고 키를 사용해야 한다. 적절한 키 관리도 해야 한다.
• 전송되는 모든 데이터는 순방향 비밀 암호를 지원하는 TLS, 서버의 암호화 방식 우선순위, 그리고 보안 파라미터 등의 보안 프로토콜로 암호화해야 한다. HSTS 같은 헤더로 암호화를 강제한다.
• 민감한 데이터를 포함하는 응답의 캐싱은 비활성화해야 한다.
• 데이터 분류에 따라 보안 레벨을 설정해야 한다.
• 민감한 데이터를 전송할 때 FTP나 SMTP 같은 낡은 프로토콜을 사용하면 안 된다.
• 패스워드는 Argon2, scrypt, bcrypt나 PBKDF2 같이 솔트를 사용하고 강력한 적응력이 있는 해싱 함수를 사용해야 한다.
• 초기 벡터는 운용 모드에 따라 적절하게 선택되어야 한다. 대부분 모드에서는 CSPRNG(암호학적 난수 생성기)를 사용하고 nonce를 사용하는 초기 벡터에서는 CSPRNG가 필수까진 아니다. 같은 키에 대해서 초기 벡터는 재사용이 되어서는 안 된다.
• 항상 일반 암호화보다는 인증 암호화를 사용해라.
• 키는 암호학적으로 안전하게 랜덤으로 생성해야 하고 메모리에 바이트 배열로 저장해야 한다. 만약 패스워드를 키로 사용할 경우 PBKDF에 의해 변환되어야 한다.
• 암호화에 사용할 난수는 적절하게 생성되어야 하며 예측 가능하거나 낮은 엔트로피로 시드되지 않아야 한다. 최신 API들은 CSPRNG에 시드를 줄 필요가 없다..
• MD5나 SHA1, PKCS1-v1.5 등 사용되지 않는 암호학적 함수나 패딩은 사용하지 않아야 한다.
• 설정과 구성의 효과는 독립적으로 검증해야 한다.