지난 2014년도에, OpenSSL 부문에서 보안 취약점이 발견되어, 관련 Library를 Update해야 하는 상황이 발생한거 같네요, 아래의 이미지는 Wiki 에서 가져온것이며, 아래의 reference site에서 원문을 보실수 있을것입니다. 그림에는 복잡하게 설명이 되어있는데요, 쉽게 설명하자면, 원격에서 서버를 공격해서 cpu 자원을 많이 사용하게끔 하는 현상이 발생되면서, 보안키를 탈취당할 가능성이 있다고 합니다. 여러 권고 사항에서는 SSL 관련 Library를 update하고, ssl key 재 생성한다음에 password까지 변경을 하라고 권고를 하고 있구요, 문제는 탈취후 시스템에 흔적이 안남는다고 하네요..
아래는 Nagios XI Lab의 전문도 함께 실어 봅니다. Nagios XI Web Page에서 Heartbleed 관련해서 해당여부 체크 가능한 web page를 제공하고, 또한 이미 Nagios Core / Nagios XI를 사용하시는 고객이라면 해당 Checker를 내려 받아서 운용하고 있는 Site에 적용되는지를 판단하는데 사용 할 수도 있을거 같습니다.
Heartbleed: One Bug to Rule Them All
If you’ve missed the news in the last few days, OpenSSL has been found to contain a rather large issue in it’s implementation of TLSv1.1 and TLS1.2 for versions 1.0.1 through 1.0.1f and 1.0.2-beta. Thankfully, no other versions contain this issue and due to responsible disclosure, a patch is already available in the form of OpenSSL 1.0.1g, which many distributions are already making available via standard package management, such as yum and apt.
As for the juicy details… Heartbleed is a vulnerability caused by a missing bounds check and lack of validation, with the TLS heartbeat extension, that allows for up to 64k of memory to be leaked to an attacker. This is done via initializing a TLS connection over TCP or UDP. When this connection is begun, a heartbeat is shared between the client and server to validate that they are both in good working order. If a malformed, specifically empty, heartbeat is sent, the responding client or server will attempt to copy memory from a packet that is not available and instead respond with data that was previously at the same location that the packet should have been located in memory on the victim’s system. The process is not limited to a newly initialized connection and may be repeated at any point in time with existing connections as well. This could result in leaked memory containing rather benign large chunks of empty memory or severe issues such as private encryption keys, session id’s, passwords, and anything else that might be in the victim’s memory.
Just to clarify, this can affect both clients and servers. Yes, your Android phone’s web browser is just as affected as your Apache web server or OpenLDAP server. So, while updating your OpenSSL version, firmware and operating system are extremely important, one must also consider applications and services that ship with internal versions of OpenSSL or include libraries with compilation that standard updates may not correct.
Resolving this on most systems including current CentOS, RHEL, and Debian based distributions can already be found via standard updates with the included package managers. Systems that do not currently provide updated versions of OpenSSL can be manually updated by building version 1.0.1g from source or building previous versions with the -DOPENSSL_NO_HEARTBEATS flag. In the case of embedded systems such as switches, routers and phones, a firmware update request may have to be made to the vendor directly.
After seeing the large effect this particular bug is having worldwide, we decided to modify existing proof of concept code and provide Nagios users with an automated way to check your systems. Through a Nagios plugin, you can now validate whether your TCP services are vulnerable to the bug with both TLSv1.1 and TLSv1.2. Soon to be implemented updates will include checking of STARTTLS vulnerabilities and UDP connections.