이 취약점은 시스템이 공격을받는 경우에도 패치 후에도 취약한 상태를 유지하며 공격으로 인해 로그에 흔적이 남지 않을 수 있으므로 잠재적으로 큰 영향을 미칩니다. 빠르게 패치를했고 유명인이 아니라면 아무도 당신을 공격하지는 않았지만 확신하기는 어렵습니다.
내가 취약한가?
버그가있는 OpenSSL 버전
버그가있는 소프트웨어는 OpenSSL 라이브러리 1.0.1 ~ 1.0.1f 및 OpenSSL 1.0.2 ~ beta1입니다. 이전 버전 (0.9.x, 1.0.0) 및 버그가 수정 된 버전 (1.0.1g 이상, 1.0.2 베타 2 이상)은 영향을받지 않습니다. 프로토콜의 결함이 아니라 구현 버그이므로 OpenSSL 라이브러리를 사용하는 프로그램 만 영향을받습니다.
명령 행 도구 openssl version -a를 사용하여 OpenSSL 버전 번호를 표시 할 수 있습니다. 일부 배포판에서는 버그 수정을 이전 릴리스로 이식합니다. 패키지의 변경 로그에 Heartbleed 버그 수정이 언급되어 있으면 1.0.1f와 같은 버전이 있어도 괜찮습니다. 경우 openssl version -a저녁 UTC 이상 주위 2014년 4월 7일의 빌드 날짜 (하지 첫 번째 줄에 날짜를) 언급, 당신은 괜찮을 것이다. 버전 이 1.0.1 인 경우에도 OpenSSL 패키지 1.0.0의 이름 이있을 수 있습니다 ( 이진 호환성 참조).1.0.0
영향을받는 응용 프로그램
익스플로잇은 OpenSSL 라이브러리를 사용하여 SSL 연결 을 구현하는 응용 프로그램을 통해 수행됩니다 . 많은 응용 프로그램이 다른 암호화 서비스를 위해 OpenSSL을 사용하고 있습니다. 버그는 SSL 프로토콜의 특정 기능인 "하트 비트"를 구현하는 데 있습니다.
시스템의 라이브러리와 어떤 프로그램이 연결되어 있는지 확인할 수 있습니다. dpkg 및 apt (Debian, Ubuntu, Mint,…)를 사용하는 시스템에서 다음 명령은 사용하는 라이브러리 이외의 설치된 패키지 libssl1.0.0(영향을받는 패키지)를 나열합니다 .
apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii lib'
이 목록에있는 일부 서버 소프트웨어 를 실행 하고 SSL 연결을 청취하는 경우, 아마도 영향을 받았을 것입니다. 이것은 웹 서버, 전자 메일 서버, VPN 서버 등과 관련이 있습니다. 인증서 서명 요청을 인증 기관에 제출하거나 자체 서명하여 인증서를 생성해야했기 때문에 SSL을 활성화했습니다. 증명서. (일부 설치 절차에서는 사용자 모르게 자체 서명 된 인증서를 생성했을 수 있지만 일반적으로 인터넷에 노출 된 서버가 아닌 내부 서버에 대해서만 수행됩니다.) 인터넷에 노출 된 취약한 서버를 실행 한 경우 손상된 것으로 간주하십시오. 2014-04-07 발표 이후 로그에 연결이 표시되지 않는 한. (이것은 발표 전에 취약점이 악용되지 않았다고 가정합니다.) 서버가 내부적으로 만 노출 된 경우,
클라이언트 소프트웨어는이 소프트웨어를 사용하여 악의적 인 서버에 연결 한 경우에만 영향을받습니다. 따라서 IMAPS를 사용하여 이메일 제공 업체에 연결 한 경우 걱정할 필요가 없습니다 (제공 업체가 공격을받지 않는 한 — 알려야하는 경우 알려야 함). 취약한 브라우저로 임의의 웹 사이트를 탐색 한 경우에는 필요할 수 있습니다. 걱정. 지금까지는 취약점이 발견되기 전에 취약점이 악용되지 않은 것으로 보이므로 2014-04-08 이후 악성 서버에 연결 한 경우에만 걱정하면됩니다.
다음 프로그램은 OpenSSL을 사용하여 SSL을 구현하지 않기 때문에 영향을받지 않습니다.
- SSH (프로토콜이 SSL이 아님)
- 크롬 / 크롬 ( NSS 사용 )
- Firefox (NSS 사용) (최소한 Ubuntu 12.04의 Firefox 27에서는 모든 빌드가 아닌가?
영향은 무엇입니까?
이 버그는 SSL 서버에 연결할 수 있는 모든 클라이언트가 한 번에 약 64kB의 메모리를 검색 할 수 있도록 합니다 . 클라이언트는 어떤 식 으로든 인증 할 필요가 없습니다. 공격을 반복함으로써 클라이언트는 메모리의 다른 부분을 연속적으로 덤프 할 수 있습니다. 이로 인해 침입자는 키, 암호, 쿠키 등 서버 프로세스의 메모리에 있던 모든 데이터를 검색 할 수 있습니다.
침입자가 검색 할 수있는 중요한 데이터 중 하나는 서버의 SSL 개인 키입니다. 이 데이터를 통해 공격자는 서버를 가장 할 수 있습니다.
또한이 버그는 SSL 클라이언트가 연결된 서버가 한 번에 약 64kB의 메모리를 검색 할 수 있도록합니다. 취약한 클라이언트를 사용하여 중요한 데이터를 조작 한 다음 나중에 동일한 클라이언트를 사용하여 신뢰할 수없는 서버에 연결하면 걱정이됩니다. 따라서이 쪽의 공격 시나리오는 서버 쪽보다 훨씬 적습니다.
일반적인 배포의 경우 패키지 의 무결성이 SSL 전송이 아닌 GPG 서명에 의존하기 때문에 패키지 배포에 보안 영향이 없습니다 .
취약점을 어떻게 해결합니까?
노출 된 서버의 치료
영향을받는 모든 서버를 오프라인 상태로 만듭니다. 실행중인 한 중요한 데이터가 유출 될 수 있습니다.
OpenSSL 라이브러리 패키지를 업그레이드하십시오 . 모든 배포판에는 현재 수정 사항이 있습니다 (1.0.1g 또는 버전 번호를 변경하지 않고 버그를 수정하는 패치). 소스에서 컴파일 한 경우 1.0.1g 이상으로 업그레이드하십시오. 영향을받는 모든 서버가 다시 시작되었는지 확인하십시오.
Linux에서는 잠재적으로 영향을받는 프로세스가 계속 실행 중인지 확인할 수 있습니다.grep 'libssl.*(deleted)' /proc/*/maps
새 키를 생성하십시오 . 이는 버그로 인해 침입자가 이전 개인 키를 얻었을 수 있기 때문에 필요합니다. 처음에 사용한 것과 동일한 절차를 따릅니다.
- 인증 기관에서 서명 한 인증서를 사용하는 경우 새 공개 키를 CA에 제출하십시오. 새 인증서를 받으면 서버에 설치하십시오.
- 자체 서명 된 인증서를 사용하는 경우 서버에 설치하십시오.
- 어느 쪽이든, 이전 키와 인증서를 방해하지 마십시오 (그러나 삭제하지 말고 더 이상 사용되지 않도록하십시오).
손상되지 않은 새로운 키가 생겼으므로 서버를 다시 온라인 상태로 만들 수 있습니다 .
이전 인증서를 해지 하십시오.
손상 평가 : SSL 연결을 제공하는 프로세스의 메모리에 있던 모든 데이터가 유출되었을 수 있습니다. 여기에는 사용자 비밀번호 및 기타 기밀 데이터가 포함될 수 있습니다. 이 데이터가 무엇인지 평가해야합니다.
- 비밀번호 인증을 허용하는 서비스를 실행하는 경우 취약점이 발표되기 조금 전에 접속 한 사용자의 비밀번호는 손상된 것으로 간주해야합니다. 로그를 확인하고 영향을받는 사용자의 비밀번호를 변경하십시오.
- 또한 모든 세션 쿠키가 손상되었을 수 있으므로 무효화하십시오.
- 클라이언트 인증서가 손상되지 않았습니다.
- 취약점이 발생하기 조금 전에 교환 된 모든 데이터는 서버의 메모리에 남아있어 공격자에게 유출되었을 수 있습니다.
- 누군가 이전 SSL 연결을 기록하고 서버 키를 검색 한 경우 이제 대화 내용을 해독 할 수 있습니다. ( PFS 가 보장 되지 않는 한 – 모르는 경우에는 그렇지 않습니다.)
다른 경우의 치료
로컬 호스트 나 인트라넷에서만 수신 대기하는 서버는 신뢰할 수없는 사용자가 연결할 수있는 경우에만 노출 된 것으로 간주됩니다.
클라이언트의 경우 버그를 악용 할 수있는 드문 시나리오가 있습니다. 악용에는 동일한 클라이언트 프로세스를 사용하여
- 기밀 데이터 (예 : 비밀번호, 클라이언트 인증서 등)를 조작합니다.
- 그런 다음 동일한 프로세스에서 SSL을 통해 악의적 인 서버에 연결됩니다.
예를 들어 (신뢰할 수없는) 메일 공급자에게만 연결하는 데 사용하는 전자 메일 클라이언트는 문제가되지 않습니다 (악의적 인 서버가 아님). 파일을 다운로드하기 위해 wget을 실행하는 것은 문제가되지 않습니다 (기밀 데이터가 유출되지 않음).
2014 년 4 월 7 일 저녁 UTC와 OpenSSL 라이브러리를 업그레이드 한 경우 클라이언트 메모리에있는 모든 데이터가 손상되는 것을 고려하십시오.
참고 문헌