Tag Archives: CVE-2014-0160

가장 많이 사용되는 SSL 및 TLS 암호화 프로토콜 중 하나인 OpenSSL에서 새로 발견된 취약점이 패치가 설치되지 않은 서버에 즉각적이고 심각한 위험으로 작용하고 있습니다. “Heartbleed(하트블리드)”라고 불리는 이 버그를 이용하면 공격자가 보안 통신을 가로채서 로그인 인증 정보, 개인 데이터, 심지어 암호 해독 키와 같은 중요 정보를 훔쳐낼 수 있습니다.

Heartbleed, 즉 OpenSSL TLS ‘하트비트’ 익스텐션 정보 공개 취약점(CVE-2014-0160)은 하트비트라는 OpenSSL의 구성 요소에 영향을 미칩니다. OpenSSL은 보편적으로 사용되는 SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 프로토콜의 오픈 소스 기술 중 하나입니다.

하트비트는 TLS 프로토콜의 익스텐션으로 실제 통신이 얼마 동안 이루어지지 않았더라도 TLS 세션이 활성 상태를 유지하게 해줍니다. 이 기능으로 두 시스템이 계속 연결되어 있고 통신 가능한 상태임을 확인할 수 있습니다. 또한 최초 연결이 끊긴 경우 사용자가 다시 보안 연결을 설정하기 위해 인증 정보를 다시 입력해야 하는 수고를 덜어줍니다.

그렇다면 하트비트는 어떻게 작동할까요? 하트비트가 OpenSSL 서버로 메시지를 보내면, 이 서버에서 다시 해당 메시지를 발신자에게 전달하여 연결을 확인합니다. 이 메시지는 최대 64KB의 페이로드라는 데이터 패킷과 이러한 페이로드의 크기에 대한 정보, 이 두 가지 구성 요소로 이루어집니다.

그러나 OpenSSL의 Heartbleed 취약점을 이용하면 공격자가 페이로드 크기에 대한 정보를 스푸핑할 수 있습니다. 이를테면 크기가 1KB에 불과한 페이로드를 보내면서 64KB라고 하는 것입니다.

이렇듯 OpenSSL 서버에서 잘못된 형식의 하트비트 메시지를 처리하는 방식이 바로 이 취약점으로 야기되는 위험성입니다. OpenSSL 서버에서는 실제로 페이로드가 메시지 표시된 크기와 같은 크기인지 확인하려 하지 않습니다. 대신 페이로드가 정확한 크기일 것으로 가정하고 해당 페이로드를 전송했던 시스템으로 다시 보내려고 시도합니다. 하지만 실제로는 페이로드에 64KB의 데이터가 들어 있지 않으므로 애플리케이션 메모리에서 이 페이로드의 옆에 저장된 데이터로 페이로드를 자동으로 채우게 됩니다. 따라서 서버에서 1KB의 페이로드를 받은 경우 메모리에 저장되어 있던 63KB의 다른 데이터를 함께 보내는 것입니다. 여기에는 사용자의 로그인 인증 정보, 개인 데이터, 경우에 따라서는 세션 및 개인 암호화 키까지 포함될 수 있습니다.

애플리케이션에서 다시 보내는 데이터는 무작위이므로 공격자가 쓸모없거나 부분적인 데이터를 받을 가능성도 있습니다. 하지만 이 취약점의 특성상 반복적인 공격이 가능하므로, 차츰 공격자가 애플리케이션에 의해 저장된 데이터를 보다 폭넓게 파악할 수 있게 됩니다.

아마도 이 공격으로 훔쳐내기 가장 힘든 정보는 개인 암호화 키일 것입니다. 데이터는 순차적으로 저장되므로 새로운 데이터가 오래된 데이터의 앞에 저장됩니다. 암호화 키는 대개 메모리에서 페이로드의 뒤에 저장되므로 액세스될 가능성이 더 낮습니다. 유출될 가능성이 가장 높은 데이터 유형은 최신 SSL/TLS 세션의 컨텐트입니다.

Heartbleed 버그는 올해 발견된 SSL/TLS 취약점 중 가장 최근에 나타난 것입니다. TLS와 그 전 세대 격인 SSL 모두 인터넷 통신용 보안 프로토콜로, 두 시스템을 오가는 트래픽을 암호화하는 방식입니다.

지난 2월 Apple은 자사 소프트웨어의 SSL에 영향을 주는 두 가지 중대한 취약점에 대한 패치를 배포했습니다. 첫 번째는 모바일 운영 체제인 iOS의 업데이트로, 공격자가 네트워크에 대해 특별한 권한을 가지고 SSL/TLS로 보호되는 세션의 데이터를 획득하거나 수정할 수 있게 하는 문제점을 해결한 것이었습니다. 며칠 후 발표된 두 번째 업데이트는 데스크탑 운영 체제인 OS X을 위한 패치였는데, 이 운영 체제 역시 동일한 취약점의 영향을 받는다는 사실이 밝혀졌기 때문입니다.

3월에는 보안 라이브러리 GnuTLS에서 인증서 취약점이 발견되었으며, 이 라이브러리는 Red Hat 데스크탑 및 서버 제품, Ubuntu 및 Debian 디스트리뷰션 등 다수의 Linux 운영 체제 버전에서 사용됩니다.

GnuTLS는 SSL/TLS의 오픈 소스 소프트웨어 기술 중 하나입니다. 이 취약점 때문에 GnuTLS에서 보안 인증서 확인 시 발생할 수 있는 몇 가지 오류를 제대로 해결하지 못했습니다. 그로 인해 공격자가 만든 특수 인증서를 이용하여 GnuTLS에서 악성 웹 사이트를 인증하도록 유도할 수 있습니다. 이 취약점에 대한 패치는 GnuTLS에서 즉시 배포했습니다.

Heartbleed는 근래 밝혀진 SSL/TLS 취약점 중 가장 심각한 유형입니다. 이 취약점은 특성상 그리고 이 버그가 가장 널리 사용되는 SSL/TLS 기술에 영향을 미친다는 사실 때문에 심각한 문제를 일으킬 수 있습니다.

기업 사용자를 위한 시만텍 권고 사항:

• Heartbleed는 OpenSSL 라이브러리의 취약점으로, SSL/TLS 또는 시만텍에서 발급하는 인증서의 결함이 아닙니다.
• OpenSSL 1.0.1~1.0.1f 사용자는 반드시 이 소프트웨어의 최신 수정 버전(1.0.1g)으로 업데이트하거나 하트 비트 익스텐션 없이 OpenSSL을 다시 컴파일해야 합니다.
• 수정된 OpenSSL 버전으로 교체한 다음에는 이미 웹 서버 인증서가 이 취약점의 익스플로잇으로 손상되었거나 도용되었을 가능성이 있다면 인증 기관에 연락하여 인증서를 교체하십시오.
• 공격받은 서버 메모리에서 유출되었을 수 있는 엔드유저 암호를 재설정하는 것을 권장합니다.

개인 사용자를 위한 시만텍 권고 사항:

• 취약한 서비스 제공업체를 이용했다면 귀하의 데이터가 타인에게 유출되었을 수 있습니다.
• 귀하가 이용하는 벤더나 업체들로부터 관련 공지 사항이 있는지 확인합니다. 취약한 벤더가 고객에게 암호를 변경해야 한다는 안내를 받으면 그에 따라 암호를 변경해야 합니다.
• 공격자가 암호를 업데이트하라는 내용의 피싱 이메일이 있을 수 있으니 주의해야 합니다. 위장 웹 사이트 접속을 방지하기 위해 공식적인 사이트 도메인만 이용합니다.
• 신뢰할 수 웹 사이트와 서비스만 이용합니다. 이러한 사이트들은 취약점 문제에 즉각적으로 대처했을 가능성이 높습니다.
• 은행 및 신용 카드 거래 명세서에 의심스러운 항목이 있는지 확인하십시오.

2014년 4월 10일 업데이트: 시만텍의 SSL Tools Certificate Checker를 통해 웹 사이트가 익스플로잇에 취약한지 여부를 확인할 수 있습니다. Certificate Checker는 아래 위치에서 이용 가능합니다.

https://ssltools.websecurity.symantec.com/checker/

Certificate Checker를 사용하려면 Check your cerftificate installation을 누른 다음 해당 웹 사이트 URL을 입력하십시오.

A newly discovered vulnerability in one of the most commonly used implementations of the SSL and TLS cryptographic protocols presents an immediate and serious danger to any unpatched server. The bug, known as Heartbleed, allows attackers to intercept secure communications and steal sensitive information such as login credentials, personal data, or even decryption keys.

Heartbleed, or the OpenSSL TLS ‘heartbeat’ Extension Information Disclosure Vulnerability (CVE-2014-0160), affects a component of OpenSSL known as Heartbeat. OpenSSL is one of the most widely used implementations of the SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols.

Heartbeat is an extension to the TLS protocol that allows a TLS session to be kept alive, even if no real communication has occurred for some time. The feature will verify that both computers are still connected and available for communication. It also saves the user the trouble of having to reenter their credentials to establish another secure connection if the original connection is dropped.

How does it work? Heartbeat sends a message to the OpenSSL server, which in turn relays that message back to the sender, verifying the connection. The message contains two components, a packet of data known as the payload which can be up to 64KB and information on the size of the payload.

However, the Heartbleed vulnerability in OpenSSL allows an attacker to spoof the information on the payload size. For example, they could send a payload of just one kilobyte in size, but state that it is 64KB.

How an OpenSSL server deals with this malformed Heartbeat message is key to the danger this vulnerability poses. It does not attempt to verify that the payload is the same size as stated by the message. Instead it assumes that the payload is the correct size and attempts to send it back to the computer it came from. However, since it doesn’t have the full 64KB of data it will instead automatically “pad out” the payload with data stored next to it in the application’s memory. If the server received a 1KB payload, it will thus send it back along with 63KB of other data stored in its memory. This could include the login credentials of a user, personal data, or even, in some cases, session and private encryption keys.

The data the application sends back is random and it is possible that the attacker may receive some incomplete or useless pieces of data. However, the nature of the vulnerability means that the attack can be performed again and again, meaning the attacker can build a bigger picture of the data stored by the application over time.

Private encryption keys may be the most difficult thing to steal using this attack. Data is stored in a sequential fashion, with new data stored in front of older data. Encryption keys will usually be stored “behind” the payload in memory, meaning they are less likely to be accessed. Content from current SSL/TLS sessions is the type of data most likely to be at risk.

The Heartbleed bug is the latest in a series of SSL/TLS vulnerabilities uncovered this year. TLS and its older predecessor SSL are both secure protocols for Internet communication and work by encrypting traffic between two computers.

In February, Apple had to patch two critical vulnerabilities affecting SSL in its software. It first issued an update for its mobile operating system iOS, which patched a flaw that enabled an attacker with a privileged network position to capture or modify data in sessions protected by SSL/TLS. Days later, a second update was issued, this time for its desktop operating system OS X, after it was discovered that the same vulnerability also affected it.

In March, a certificate vulnerability was found in security library GnuTLS, which is used in a large number of Linux versions, including Red Hat desktop and server products, and Ubuntu and Debian distributions of the operating system.

GnuTLS is an open source software implementation of SSL/TLS. The bug meant that GnuTLS failed to correctly handle some errors that could occur when verifying a security certificate. This could allow an attacker to use a specially crafted certificate to trick GnuTLS into trusting a malicious website. The vulnerability was immediately patched by GnuTLS.

Heartbleed is by far the most serious vulnerability in SSL/TLS to be uncovered of late. The nature of the bug and the fact that affects one of the most widely used implementations of SSL/TLS means that it poses an immediate risk.

Advice for businesses:

• Anyone using OpenSSL 1.0.1 through 1.0.1f should update to the latest fixed version of the software (1.0.1g), or recompile OpenSSL without the heartbeat extension
• After moving to a fixed version of OpenSSL, if you believe your web server certificates may have been compromised or stolen as a result of exploitation, contact the certificate authority for a replacement
• Finally, and as a best practice, businesses should also consider resetting end-user passwords that may have been visible in a compromised server memory

Advice for consumers:

• You should be aware that your data could have been seen by a third party if you used a vulnerable service provider
• Monitor any notices from the vendors you use. Once a vulnerable vendor has communicated customers that they should change their passwords, users should do so
• Avoid potential phishing emails from attackers asking you to update your password – to avoid going to an impersonated website, stick with the official site domain
• Stick to reputable websites and services. They are most likely to have immediately addressed the vulnerability
• Monitor your bank and credit card statements to check for any unusual transactions