☰

OpenSSL에서 Heartbleed 오류를 복구하는 방법은 무엇입니까?

tag-icon • tag-icon security openssl
OpenSSL에서 Heartbleed 오류를 복구하는 방법은 무엇입니까?

CVE-2014-0160또한 ~으로 알려진힘든 노력OpenSSL의 취약점입니다. 무서워 보인다.

내가 영향을 받았는지 어떻게 알 수 있나요?

영향을 받은 경우 어떻게 해야 합니까? 업그레이드만으로는 충분하지 않은 것 같습니다.

답변1

이 취약점은 시스템이 공격을 받을 경우 패치를 적용한 후에도 취약한 상태로 유지되고 공격이 로그에 흔적을 남기지 않을 수 있으므로 잠재적인 영향이 높습니다. 빠르게 패치하고 세간의 이목을 끄는 대상이 아니라면 아무도 당신을 공격하지 않을 가능성이 높지만 확실히 알기는 어렵습니다.

나는 취약한가?

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 -aOpenSSL 버전 번호를 표시할 수 있습니다. 일부 배포판에서는 버그 수정을 이전 버전으로 백포트합니다. 패키지 변경 로그에 Heartbleed 버그 수정이 언급되어 있으면 1.0.1f와 같은 버전이 표시되더라도 괜찮습니다. openssl version -a언급된 빌드 날짜(첫 번째 줄의 날짜가 아님)가 2014년 4월 7일(UTC) 저녁 무렵이거나 그 이후라면 괜찮을 것입니다 . OpenSSL 1.0.0패키지 에는이름하지만버전1.0.1입니다( 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년 4월 7일 이후 로그에 연결이 표시되지 않는 한 손상된 것으로 간주하십시오. (이는 릴리스 이전에 취약점이 악용되지 않았다고 가정합니다.) 서버가 내부적으로만 노출된 경우 키를 변경해야 하는지 여부는 추가 보안 조치가 적용되어 있는지 여부에 따라 달라집니다.

클라이언트 소프트웨어는 이를 사용하여 악성 서버에 연결하는 경우에만 영향을 받습니다. 따라서 IMAPS를 사용하여 이메일 제공업체에 연결하는 경우에는 걱정할 필요가 없습니다(제공업체가 손상되지 않는 한 - 그러나 그러한 경우 알려야 함). 그러나 취약한 브라우저로 검색하는 경우 Random 걱정해야 할 웹사이트. 현재까지 해당 취약점이 발견되기 전에는 악용된 사례가 없는 것으로 나타나, 2014년 4월 8일 이후부터는 악성 서버 연결만 걱정하시면 됩니다.

다음 프로그램은 OpenSSL을 사용하여 SSL을 구현하지 않으므로 영향을 받지 않습니다.

  • SSH(SSL이 아닌 프로토콜)
  • 크롬/크롬(NSS 사용)
  • Firefox(NSS 사용)(Ubuntu 12.04에서는 Firefox 27 이상이지만 모든 버전은 아님?)

어떤 영향이 있나요?

이 오류는모든 고객SSL 서버에 연결하여 한 번에 서버에서 약 64kB의 메모리를 검색할 수 있는 사람. 클라이언트는 어떤 방식으로든 인증할 필요가 없습니다. 반복 공격을 통해 클라이언트는 연속적인 시도에서 메모리의 다른 부분을 덤프할 수 있습니다. 이를 통해 공격자는 키, 비밀번호, 쿠키 등을 포함하여 서버 프로세스 메모리의 모든 데이터를 검색할 수 있습니다.

공격자가 검색할 수 있는 주요 데이터 중 하나는 서버의 SSL 개인 키입니다. 이 데이터를 사용하여 공격자는 귀하의 서버를 가장할 수 있습니다.

또한 이 버그는 SSL 클라이언트가 연결하는 모든 서버가 한 번에 클라이언트에서 약 64kB의 메모리를 검색할 수 있도록 허용합니다. 취약한 클라이언트를 사용하여 민감한 데이터를 조작한 다음 동일한 클라이언트를 사용하여 신뢰할 수 없는 서버에 연결하는 경우 걱정할 것이 있습니다. 따라서 이쪽의 공격 가능성은 서버 측에 비해 현저히 낮습니다.

일반적인 분포의 경우패키지 배포에 보안 영향 없음패키지의 무결성은 SSL 전송이 아닌 GPG 서명에 의존하기 때문입니다.

이 취약점을 해결하는 방법은 무엇입니까?

노출된 서버 수리

  1. 영향을 받는 모든 서버를 오프라인으로 전환합니다.실행되는 동안 중요한 데이터가 유출될 가능성이 있습니다.

  2. OpenSSL 라이브러리 패키지 업그레이드. 모든 배포판에는 이제 수정 사항이 있어야 합니다(1.0.1g 또는 버전 번호를 변경하지 않고 버그를 수정하는 패치 포함). 소스에서 컴파일하는 경우 1.0.1g 이상으로 업그레이드하시기 바랍니다. 영향을 받는 모든 서버가 다시 시작되었는지 확인하세요.
    Linux에서는 잠재적으로 영향을 받는 프로세스가 아직 실행 중인지 확인할 수 있습니다.grep 'libssl.*(deleted)' /proc/*/maps

  3. 새 키 생성. 이는 버그로 인해 공격자가 이전 개인 키를 얻을 수 있기 때문에 필요합니다. 처음에 사용한 것과 동일한 단계를 따르세요.

    • 인증 기관에서 서명한 인증서를 사용하는 경우 새 공개 키를 CA에 제출하세요. 새 인증서가 있으면 서버에 설치하십시오.
    • 자체 서명된 인증서를 사용하는 경우 서버에 설치하십시오.
    • 어느 쪽이든 이전 키와 인증서를 다른 곳으로 옮기십시오(단, 삭제하지 말고 더 이상 사용하지 않는지 확인하세요).

  4. 이제 손상되지 않은 새 키가 있으므로 다음을 수행할 수 있습니다.서버를 다시 온라인 상태로 전환.

  5. 취소오래된 인증서.

  6. 피해 평가: SSL 연결을 제공하는 프로세스의 메모리에 있는 모든 데이터가 손상되었을 수 있습니다. 여기에는 사용자 비밀번호 및 기타 기밀 데이터가 포함될 수 있습니다. 이 데이터가 무엇인지 평가해야 합니다.

    • 비밀번호 인증을 허용하는 서비스를 실행하는 경우, 취약점이 발표되기 직전에 연결한 사용자의 비밀번호는 손상된 것으로 간주해야 합니다. 로그를 확인하고 영향을 받는 사용자의 비밀번호를 변경하세요.
    • 또한 모든 세션 쿠키가 손상되었을 수 있으므로 무효화하십시오.
    • 클라이언트 인증서는 손상되지 않습니다.
    • 취약점이 발생하기 직전부터 교환된 모든 데이터는 서버 메모리에 남아 있어 공격자에게 유출되었을 수 있습니다.
    • 누군가가 기존 SSL 연결을 기록하고 서버 키를 검색한 경우 이제 로그를 해독할 수 있습니다. (하지 않는 한무진행 생존보장됩니다. 모르신다면 그렇지 않습니다. )

기타 상황에 대한 구제책

localhost 또는 인트라넷에서만 수신 대기하는 서버는 신뢰할 수 없는 사용자가 해당 서버에 연결할 수 있는 경우에만 노출된 것으로 간주됩니다.

클라이언트의 경우 이 버그가 악용될 수 있는 경우는 매우 드뭅니다. 취약점을 악용하려면 동일한 클라이언트 프로세스를 사용해야 합니다.

  1. 기밀 데이터(예: 비밀번호, 클라이언트 인증서...)를 조작합니다.
  2. 이후 동일한 과정에서 SSL을 통해 악성 서버에 연결됩니다.

따라서 예를 들어 완전히 신뢰할 수 없는 메일 제공업체에 연결하는 데만 사용하는 이메일 클라이언트는 문제가 아닙니다(악성 서버가 아님). 파일을 다운로드하기 위해 wget을 실행하는 것은 문제가 되지 않습니다(기밀 데이터는 유출되지 않습니다).

이 작업을 수행하고 2014년 4월 7일(UTC) 저녁 사이에 OpenSSL 라이브러리를 업그레이드하는 경우 클라이언트 메모리의 모든 데이터가 손상된다는 점을 고려하세요.

인용하다

답변2

취약한지 테스트하려면 여기로 이동하세요.http://filippo.io/Heartbleed/

취약하다고 판단되면 openssl웹 서버를 업데이트하고 다시 시작하세요.

답변3

이 오류를 복구할 수 있는 방법은 없습니다. 모든 로그를 보관하십시오. 취약점을 발표하기 전에 누군가 취약점이 실제로 존재한다는 사실을 깨닫는 경우 필요합니다.

관련 정보