Heartbleed가 처음 발견된 지 6년이 지났지만 OpenSSL 취약성은 여전히 인터넷을 통해 발견되고 악용될 수 있습니다. 실제로 글로벌 공격의 19%는 패치되지 않은 공개 서버 볼륨으로 인해 OpenSSL Heartbleed 취약성을 대상으로 합니다. 검색이 제대로 되지 않거나 프로덕션 서버 재부팅에 대한 두려움으로 인해 서버를 OpenSSL 악용에 개방하면 고객과 데이터가 위험에 노출됩니다. 이 기사에서는 Heartbleed와 데이터 개인 정보 보호 및 규정 준수에 대한 위협에 대해 자세히 설명합니다. 또한 프로세스에서 오래된 라이브러리를 Disk에서 업데이트한 경우에도 사용하는지 확인하는 방법에 대해서도 설명합니다.
Heartbleed에 대한 간단한 개요
OpenSSL은 클라이언트와 서버 간의 암호화된 통신을 용이하게 하는 오픈 소스 라이브러리입니다. 오픈 소스이기 때문에 누구나 코드베이스에 기여하여 자신의 서버 통신 프로토콜에 사용할 수 있습니다. 이 취약한 코드는 2011년에 추가되었으며 2012년에 릴리스되었습니다. 구글의 연구원들은 2014년이 되어서야 이 취약한 코드를 발견했습니다.
TLS/SSL 사용 서버와 클라이언트 간에 초기 핸드셰이크가 이루어지면, 클라이언트는 16비트 정수 "메시지"를 서버로 보내고 동일한 메시지가 클라이언트로 다시 전송됩니다. TLS/SSL 연결이 보안 통신을 시작하려면 이 초기 핸드셰이크가 필요합니다. 요청이 있을 때 서버는 16비트 메시지에 메모리를 할당합니다.
Heartbleed 익스플로잇은 서버에 잘못된 형식의 초기 핸드셰이크 메시지를 보냅니다. 즉, 메시지가 특정 길이로 구성되어 있다고 주장하는 메시지를 의미하지만 실제로는 훨씬 작습니다. 예를 들어, 클라이언트의 초기 핸드셰이크 메시지는 길이가 64바이트이지만 8바이트라고 주장합니다. 서버는 이 잘못된 형식의 요청을 수신하면 인접한 메모리 값을 읽고 다시 클라이언트로 보내서 클라이언트에 반환된 나머지 비트를 패딩합니다. 인접한 이 메모리는 가비지 값일 수도 있고, 사용자 자격 증명, 통신 암호를 해독하는 데 사용되는 개인 키 또는 개인 식별 정보(PII)일 수도 있습니다.
Hartbleed의 발견은 매우 중요했으며, 관리자는 OpenSSL 1.0.1 ~ 1.0 및 1.0.2 베타 1.1f를 사용하는 모든 서버를 이미 이용할 수 있는 최대한 빨리 패치해야 했습니다. Netcraft 연구에 따르면 SSL 서버의 17%(약 500,000대)가 Heartbleed에 취약한 것으로 나타났습니다. 연구에 따르면 2014년에 하트블리드 취약성이 보고되었지만 여전히 많은 공용 서버 및 사용자 장치에서 문제가 되고 있습니다.
관리자가 서버 패치를 적용하지 못하는 이유
취약한 서버의 분명한 해결책은 패치를 적용하는 것이지만 중요한 프로덕션 서버에 패치를 적용하는 것은 표준 사용자 장치보다 훨씬 더 섬세하고 위험합니다. 이러한 이유로 관리자는 취약성이 발견된 후 몇 주가 걸릴 수 있는 비수기 업무 시간에 패치 적용을 예약합니다. 공격 코드를 사용할 수 있는 취약성은 즉시 악용될 수 있으며 공격자가 자체 악성 프로그램을 개발할 필요가 없으므로 데이터 개인 정보에 특히 위험합니다.
관리자는 재부팅과 관련된 위험 때문에 서버를 패치하지 않은 상태로 두는 경우가 많습니다. 현재 패치 및 재부팅 예약은 두 가지 주요 이유로 인해 위험합니다.
서버 다운타임이 발생했습니다. 문제 없이 원활하게 재부팅해도 15분 이상이 걸릴 수 있습니다. 이 시간 동안에는 서비스를 사용할 수 없습니다. 대기업은 서버 다운타임에 대한 내성이 낮기 때문에 중요한 서버를 재부팅하려면 프로덕션에서 페일오버가 필요합니다. 로드 밸런서 뒤에서 여전히 순환 중인 페일오버 또는 서버는 오버로드될 수 있으며 트래픽 로드를 처리할 수 없습니다.
취약성의 창입니다. 대규모 조직에서는 서버를 매달 패치하고 재부팅하는 것이 일반적입니다. 몇 주 동안 서버를 개방된 위협에 취약하게 만들 수 있습니다. 취약성의 창이 클수록 공격자가 공격 및 최신 위협에 대해 열려 있는 서버를 검색하고 찾을 가능성이 높아집니다.
재부팅이 필요 없는 수동 패치 적용 및 잘못된 방법
OpenSSL 외에도, 오픈 소스 커뮤니티에는 중요한 프로덕션 서버에서 실행되는 수많은 공유 라이브러리가 있지만, 서버를 안전하게 유지하려면 운영 체제 패치와 함께 이러한 라이브러리를 패치해야 합니다. 일부 관리자는 다운타임이 위험하지 않도록 재부팅하지 않고 서버에 수동으로 패치를 적용합니다. 올바른 실시간 패치 적용 도구가 없으면 재부팅하지 않고 패치를 적용하면 메모리에 취약한 코드가 남지만 디스크 및 서버의 패치된 버전은 취약한 상태로 유지됩니다.
관리자가 재부팅이 필요 없는 패치 적용 서버에 대해 취약성 스캐너를 실행하면 스캐너가 패치된 디스크 버전을 탐지하여 잘못된 부정값을 반환합니다. 메모리에서 패치되지 않은 버전을 실행하는 패치된 라이브러리는 여전히 취약하므로 서버를 패치하는 데 비효율적인 방법입니다.
잘못된 네거티브를 찾으려면 디스크 결과를 사용하는 대신 메모리 내 취약한 라이브러리를 탐지하는 스캐너가 필요합니다.
커널케어의 Uchecker는 FOSS 커뮤니티가 디스크에 패치를 적용했더라도 취약한 서버를 찾을 수 있도록 지원하는 오픈 소스 스캐너 중 하나입니다.
JSON으로 구축된 자유 소프트웨어이며 GNU General Public License의 조건에 따라 재배포 및/또는 수정이 가능합니다. Uchecker는 오래된 공유 라이브러리(즉, 패치되지 않은)를 사용하는 프로세스를 탐지합니다. 실행 중인 프로세스에서 사용 중인 최신 공유 라이브러리를 탐지하고 보고합니다. 관리자는 커널케어의 스캐너를 사용하여 취약한 공유 라이브러리의 프로세스 ID와 이름 및 라이브러리의 빌드 ID를 얻을 수 있습니다. 이 정보는 취약성과 문제를 해결하는 데 필요한 패치를 식별하는 데 사용할 수 있습니다.
메모리의 오래된 공유 라이브러리가 Uchecker에 의해 식별되었습니다.
Uchecker(사용자 공간 검사기의 줄임말)는 버전 6부터 모든 최신 리눅스 배포판과 함께 작동합니다. 다음 그래픽 그림에서는 Uchecker의 작동 방식을 보여 줍니다.
Uchecker는 한 가지 명령만 사용하여 시스템에서 오래된 공유 라이브러리를 검색합니다.
curl -s -L https://kernelcare.com/checker | python
UCchecker의 Github 페이지를 방문하여 자세한 내용을 보거나 작동 방법에 대한 데모를 보십시오.
UCchecker와 같은 효율적인 취약성 스캐너를 사용하고 적절한 실시간 패치 관리를 구현하면 재부팅과 관련된 위험이 상당 부분 제거되고 오픈 소스 라이브러리는 계속 업데이트됩니다. 특히 OpenSSL과 같은 개인 키 및 사용자 자격 증명을 잠재적으로 노출시킬 수 있는 취약한 라이브러리에 대한 패치 적용 속도를 높이는 것이 중요합니다. 현재 많은 서버가 재부팅으로 인해 발생할 수 있는 문제로 인해 패치를 사용할 수 있는 후에도 몇 주 동안 취약하게 남아 있지만, 이로 인해 조직은 규정 준수를 준수하지 못하고 심각한 데이터 침해의 위험이 있습니다. 멀웨어바이트는 수천 개의 웹 사이트가 여전히 Heartbleed에 취약하다고 보고하며, 이러한 웹 사이트에 연결하는 모든 사용자는 데이터 개인 정보 문제에 대해 열려 있습니다. 올바른 실시간 패치 및 취약성 검색 솔루션을 사용하면 관리자가 이러한 서버에 패치를 적용하고 고객의 공개를 중지하고 ID 도용 및 계정 탈취로부터 보호할 수 있습니다.
'SW > 리눅스' 카테고리의 다른 글
| Linux : Wall 명령어, 예제, 사용 방법 (0) | 2022.12.19 |
|---|---|
| Linux : CentOS 8 : Slack 설치 방법, 예제, 명령어 (0) | 2022.12.18 |
| Python : 리스트의 길이 찾는 방법, 예제, 명령어 (0) | 2022.12.16 |
| Linux : Ubuntu 20.04 : FFmpeg 설치, 사용 방법, 예제, 명령어 (0) | 2022.12.15 |
| Linux : Cron Job을 5, 10, 15분 마다 실행 방법, 예제, 명령어 (0) | 2022.12.14 |