HTTPS에 대한 잠재적인 공격과 이를 방지하는 방법

사이트의 절반 HTTPS를 사용합니다, 그 수는 꾸준히 증가하고 있습니다. 프로토콜은 트래픽 가로채기의 위험을 줄이지만 공격 시도를 제거하지는 않습니다. POODLE, BEAST, DROWN 등 일부 항목과 자료의 보호 방법에 대해 이야기하겠습니다.

/플리커/ 스벤 그레이엄 /CC BY-SA

푸들

공격에 대해 처음으로 푸들 2014년에 알려졌습니다. Google의 정보 보안 전문가 Bodo Möller와 동료들이 SSL 3.0 프로토콜의 취약점을 발견했습니다.

그 본질은 다음과 같습니다. 해커는 클라이언트가 SSL 3.0을 통해 연결되도록 강제하여 연결 중단을 에뮬레이트합니다. 그런 다음 암호화된 항목을 검색합니다. CBC-교통 모드 특수 태그 메시지. 일련의 위조된 요청을 사용하여 공격자는 쿠키와 같은 관심 데이터의 내용을 재구성할 수 있습니다.

SSL 3.0은 오래된 프로토콜입니다. 그러나 그의 안전에 대한 문제는 여전히 관련이 있습니다. 클라이언트는 서버와의 호환성 문제를 피하기 위해 이를 사용합니다. 일부 데이터에 따르면 가장 인기 있는 사이트 7만 개 중 거의 100%가 여전히 SSL 3.0을 지원합니다. 또한 존재하다 최신 TLS 1.0 및 TLS 1.1을 대상으로 하는 POODLE 수정. 올해 출연 한 TLS 1.2 보호를 우회하는 새로운 Zombie POODLE 및 GOLDENDOODLE 공격(여전히 CBC 암호화와 연결되어 있음)

자신을 보호하는 방법. 원본 POODLE의 경우 SSL 3.0 지원을 비활성화해야 합니다. 그러나 이 경우 호환성 문제가 발생할 위험이 있습니다. 대체 솔루션은 TLS_FALLBACK_SCSV 메커니즘일 수 있습니다. 이는 SSL 3.0을 통한 데이터 교환이 이전 시스템에서만 수행되도록 보장합니다. 공격자는 더 이상 프로토콜 다운그레이드를 시작할 수 없습니다. Zombie POODLE 및 GOLDENDOODLE로부터 보호하는 방법은 TLS 1.2 기반 애플리케이션에서 CBC 지원을 비활성화하는 것입니다. 기본 솔루션은 TLS 1.3으로의 전환입니다. 새 버전의 프로토콜은 CBC 암호화를 사용하지 않습니다. 대신 내구성이 더 뛰어난 AES와 ChaCha20이 사용됩니다.

비스트

1.0년에 발견된 SSL 및 TLS 2011에 대한 최초의 공격 중 하나입니다. 푸들, 비스트처럼 использует CBC 암호화 기능. 공격자는 TLS 또는 SSL을 통해 데이터를 전송할 때 메시지를 대체하는 JavaScript 에이전트 또는 Java 애플릿을 클라이언트 시스템에 설치합니다. 공격자는 "더미" 패킷의 내용을 알고 있으므로 이를 사용하여 초기화 벡터를 해독하고 서버에 보내는 인증 쿠키와 같은 다른 메시지를 읽을 수 있습니다.

현재까지 BEAST 취약점은 남아있습니다. 다수의 네트워크 도구가 취약함: 로컬 인터넷 게이트웨이를 보호하기 위한 프록시 서버 및 애플리케이션입니다.

자신을 보호하는 방법. 공격자는 데이터를 해독하기 위해 정기적인 요청을 보내야 합니다. VMware에서 추천하다 SSLSessionCacheTimeout의 기간을 30분(기본 권장 사항)에서 2020초로 줄입니다. 이 접근 방식은 공격자가 계획을 실행하는 것을 더 어렵게 만들지만 성능에는 어느 정도 부정적인 영향을 미치게 됩니다. 또한 BEAST 취약점은 곧 저절로 과거의 일이 될 수 있다는 점을 이해해야 합니다. XNUMX년 이후로 가장 큰 브라우저는 멈추다 TLS 1.0 및 1.1을 지원합니다. 어쨌든 모든 브라우저 사용자 중 1,5% 미만이 이러한 프로토콜을 사용합니다.

안 들리게 하다

이는 2비트 RSA 키를 사용하는 SSLv40 구현의 버그를 악용하는 크로스 프로토콜 공격입니다. 공격자는 대상의 수백 개의 TLS 연결을 수신하고 동일한 개인 키를 사용하여 SSLv2 서버에 특수 패킷을 보냅니다. 사용 블레이헨바커 공격, 해커는 약 천 개의 클라이언트 TLS 세션 중 하나를 해독할 수 있습니다.

DROWN은 2016년에 처음 알려졌습니다. 서버의 XNUMX분의 XNUMX이 영향을 받음 세상에. 오늘날 그것은 관련성을 잃지 않았습니다. 150만 개의 가장 인기 있는 사이트 중 2%는 여전히 지지 SSLv2 및 취약한 암호화 메커니즘.

자신을 보호하는 방법. SSLv2 지원을 비활성화하는 암호화 라이브러리 개발자가 제안한 패치를 설치해야 합니다. 예를 들어, OpenSSL에 대한 두 가지 패치가 제공되었습니다(2016년). 이건 업데이트였어 1.0.1초 및 1.0.2g). 또한 취약한 프로토콜을 비활성화하기 위한 업데이트와 지침이 다음에 게시되었습니다. 레드햇, 아파치, 데비안.

개발 부서장은 "메일 서버와 같이 SSLv2를 사용하는 제XNUMX자 서버에서 해당 키를 사용하는 경우 해당 리소스가 DROWN에 취약할 수 있습니다"라고 말합니다. IaaS 제공업체 1cloud.ru 세르게이 벨킨. — 이 상황은 여러 서버가 공통 SSL 인증서를 사용하는 경우 발생합니다. 이 경우 모든 시스템에서 SSLv2 지원을 비활성화해야 합니다."

특별한 방법을 사용하여 시스템을 업데이트해야 하는지 확인할 수 있습니다. 유용 — DROWN을 발견한 정보보안 전문가들이 개발했습니다. 이러한 유형의 공격에 대한 보호와 관련된 권장 사항에 대한 자세한 내용은 다음에서 확인할 수 있습니다. OpenSSL 웹사이트에 게시.

Heartbleed와

소프트웨어의 가장 큰 취약점 중 하나는 Heartbleed와. 이는 2014년 OpenSSL 라이브러리에서 발견되었습니다. 버그 발표 당시 취약한 웹사이트 수 XNUMX만 명으로 추산됐다. - 이는 네트워크에서 보호되는 리소스의 약 17%입니다.

공격은 소형 Heartbeat TLS 확장 모듈을 통해 구현됩니다. TLS 프로토콜에서는 데이터가 지속적으로 전송되어야 합니다. 가동 중지 시간이 길어지면 연결이 끊어지고 연결을 다시 설정해야 합니다. 문제에 대처하기 위해 서버와 클라이언트는 인위적으로 채널에 "노이즈"를 발생시킵니다(RFC 6520, 5페이지), 임의 길이의 패킷을 전송합니다. 전체 패킷보다 큰 경우 취약한 버전의 OpenSSL은 할당된 버퍼를 초과하는 메모리를 읽습니다. 이 영역에는 개인 암호화 키 및 기타 연결에 대한 정보를 포함한 모든 데이터가 포함될 수 있습니다.

이 취약점은 1.0.1에서 1.0.1f 사이의 모든 라이브러리 버전뿐만 아니라 Ubuntu 최대 12.04.4, CentOS 6.5 이전, OpenBSD 5.3 등 다양한 운영 체제에도 존재합니다. 전체 목록이 있습니다 Heartbleed 전용 웹사이트에서. 이 취약점에 대한 패치는 발견 직후 출시되었지만 문제는 오늘날까지도 여전히 관련이 있습니다. 2017년에 다시 거의 200만 개의 사이트가 작동했습니다., Heartbleed에 취약합니다.

자신을 보호하는 방법. 필요하다. OpenSSL 업데이트 버전 1.0.1g 이상까지. DOPENSSL_NO_HEARTBEATS 옵션을 사용하여 하트비트 요청을 수동으로 비활성화할 수도 있습니다. 업데이트 이후에는 정보보안 전문가들이 추천하다 SSL 인증서를 재발급하세요. 암호화 키의 데이터가 해커의 손에 들어갈 경우를 대비해 교체가 필요합니다.

인증서 대체

합법적인 SSL 인증서가 있는 관리 노드가 사용자와 서버 사이에 설치되어 트래픽을 적극적으로 차단합니다. 이 노드는 유효한 인증서를 제시하여 합법적인 서버를 가장하며, MITM 공격이 가능해진다.

에 따르면 연구 Mozilla, Google 및 여러 대학의 팀에서는 네트워크 보안 연결의 약 11%가 도청됩니다. 이는 사용자 컴퓨터에 의심스러운 루트 인증서를 설치한 결과입니다.

자신을 보호하는 방법. 믿을 수 있는 서비스를 이용해 보세요 SSL 제공업체. 서비스를 이용하여 인증서의 '품질'을 확인할 수 있습니다. 인증서 투명성 (CT). 클라우드 제공업체는 도청 탐지에도 도움을 줄 수 있으며, 일부 대기업은 이미 TLS 연결 모니터링을 위한 전문 도구를 제공하고 있습니다.

또 다른 보호 방법은 새로운 것입니다. 표준 SSL 인증서 수신을 자동화하는 ACME. 동시에 사이트 소유자를 확인하는 추가 메커니즘이 추가됩니다. 그것에 대해 더 알아보기 우리는 이전 자료 중 하나에 썼습니다.

/플리커/ 유리 사모일로프 /CC BY

HTTPS에 대한 전망

수많은 취약점에도 불구하고 IT 거대 기업과 정보 보안 전문가는 프로토콜의 미래를 확신하고 있습니다. HTTPS의 적극적인 구현을 위해 옹호자 WWW 제작자 팀 버너스리. 그에 따르면 시간이 지남에 따라 TLS의 보안이 더욱 강화되어 연결 보안이 크게 향상될 것이라고 합니다. Berners-Lee는 심지어 다음과 같이 제안했습니다. 미래에 나타날 것이다 신원 인증을 위한 클라이언트 인증서. 공격자로부터 서버를 보호하는 데 도움이 됩니다.

머신러닝을 활용한 SSL/TLS 기술도 개발할 계획이다. 스마트 알고리즘이 악성 트래픽 필터링을 담당하게 된다. HTTPS 연결을 사용하면 관리자는 맬웨어의 요청 탐지를 포함하여 암호화된 메시지의 내용을 찾을 수 없습니다. 이미 오늘날 신경망은 잠재적으로 위험한 패킷을 90%의 정확도로 필터링할 수 있습니다. (프레젠테이션 슬라이드 23).

조사 결과

HTTPS에 대한 대부분의 공격은 프로토콜 자체의 문제가 아니라 오래된 암호화 메커니즘을 지원하는 것과 관련이 있습니다. IT 산업은 이전 세대 프로토콜을 점차적으로 포기하고 취약점 검색을 위한 새로운 도구를 제공하기 시작했습니다. 앞으로 이러한 도구는 점점 더 지능화될 것입니다.

해당 주제에 대한 추가 링크:

• 클라우드 개발, 정보 보안 및 개인 데이터: 1cloud에서 다이제스트
• SSL 다이제스트: Habré 등에 관한 최고의 실용적인 자료
• VPN 다이제스트: Habré 등에 대한 소개 기사

출처 : habr.com