OpenSSL은 컴퓨터 네트워크를 통한 보안 통신을 구현하기 위해 널리 사용되는 오픈 소스 소프트웨어 라이브러리입니다. 얼마나 널리 사용됩니까? 글쎄요, HTTPS 웹 페이지에 액세스한 적이 있다면 OpenSSL 암호화를 통해 액세스했을 가능성이 있습니다. 라이브러리는 데이터 암호화, 암호 해독, 인증 및 디지털 서명 확인을 위한 암호화 기능과 프로토콜을 제공합니다. OpenSSL은 웹 서버, 이메일 서버, 가상 사설망(VPN) 및 기타 유형의 네트워크 통신을 보호해야 하는 거의 모든 곳에서 찾을 수 있습니다.
위의 단락을 보면 OpenSSL이 인터넷의 올바른 작동에 얼마나 중요한지 분명해집니다. 이는 많은 컴퓨터 시스템 및 애플리케이션에 대한 보안 인프라의 중요한 구성 요소입니다. 이는 중요한 데이터를 무단 액세스로부터 보호하고 네트워크 통신의 무결성과 신뢰성을 보장하는 데 도움이 됩니다. 그렇기 때문에 라이브러리 관리자는 취약점을 매우 심각하게 받아들이고 가능한 한 빨리 패치를 시도합니다. 공격자가 월드 와이드 웹 인프라의 보안 통신 회선에 액세스하는 것을 상상하는 것은 거의 상상할 수 없습니다.
이 기사에서는 3.0.7년 2022월 OpenSSL 패치 XNUMX을 촉발한 취약점을 조사하고 OpenSSL 관리자가 문제를 처리한 방식에서 무엇을 배울 수 있는지 살펴보겠습니다.
취약점
25년 2022월 XNUMX일 OpenSSL 프로젝트는 자문 일부 문제를 해결하기 위해 새로운 패치가 곧 나올 것이라고 경고합니다. 임계 취약점. '중요' 태그는 취약점이 악용될 가능성이 있고 영향을 받는 서버에서 개인 키 및/또는 RCE가 도용될 가능성이 있음을 의미합니다.
일주일 후인 1년 2022월 3.0.7일에 OpenSSL 프로젝트는 새로운 패치 XNUMX과 특정 취약점 그들은 고치는 것을 목표로 하고 있었습니다. 그 사이에 취약점 등급이 심각에서 '심각도 높음'으로 하향 조정되었습니다.
그렇다면 이러한 취약점은 무엇입니까?
CVE-2022-3602 – X.509 이메일 주소 4바이트 버퍼 오버런 – X.509 인증서 확인, 특히 이름 제약 조건 검사에서 XNUMX바이트의 버퍼 오버런이 발생할 수 있습니다. 공격자가 악의적인 이메일 주소를 사용하면 스택에 있는 공격자 제어 바이트 XNUMX개가 오버플로될 수 있습니다. 이 버퍼 오버플로로 인해 충돌(서비스 거부로 이어짐) 또는 원격 코드 실행이 발생할 수 있습니다. 처음에는 중요 항목으로 분류되었지만 추가 테스트를 통해 수많은 플랫폼에서 원격 코드 실행 위험을 줄이기 위해 스택 오버플로 보호 장치를 사용하는 것으로 나타났습니다.
CVE-2022-3786 – X.509 이메일 주소 가변 길이 버퍼 오버플로 – X.509 인증서 확인, 특히 이름 제약 조건 검사에서 버퍼 오버런이 발생할 수 있습니다. 공격자는 인증서에 악성 이메일 주소를 생성하여 십진수 46인 "." 문자가 포함된 바이트 수로 스택을 채울 수 있습니다. 이 버퍼 오버플로로 인해 충돌이 발생할 수 있습니다. 서비스 거부).
이러한 취약점이 얼마나 심각한지 다시 한 번 말씀드리겠습니다.즉, 미국 사이버 보안 및 인프라 보안 기관인 CISA가 발표한 내용입니다. 자문 OpenSSL과 같은 날, encoura사용자와 관리자에게 OpenSSL 문서화 및 해당되는 경우 새 패치 3.0.7로 업그레이드합니다.
앞에서 설명한 것처럼 OpenSSL을 실행하는 운영 체제나 메일 서버의 RCE(원격 코드 실행)는 매우 좋지 않으므로 적절한 패치가 발견되어 제공되면 취약점이 해결됩니다.
무엇이 다음에 일어날
초기 권고가 발표되자마자 사람들은 뒤섞이기 시작했습니다. '당황하지 마세요'는 흔한 표현이었습니다 당시에 OpenSSL이 중요하다는 소식을 사람들이 얼마나 심각하게 받아들이는지 보여줍니다. 취약점.
권고가 게시되자마자 모든 관련 이해관계자는 자신의 서버, OS, 애플리케이션, 패키지 등에 어떤 버전의 OpenSSL이 사용되었는지 알아내려고 애썼습니다. 내부 OpenSSL 사용뿐만 아니라 사람들은 자신의 세 번째 OpenSSL 사용 버전도 알아내야 했습니다. 파티 공급업체나 서비스 제공업체가 취약한 OpenSSL 버전을 사용하고 있었습니다. 당시에는 어떤 버전을 사용하고 있는지 확실하지 않거나 공급업체 및 서비스 제공업체가 어떤 버전을 사용하고 있는지 확실하지 않은 경우 잠재적인 RCE 위험을 감수하는 것보다 애플리케이션을 오프라인으로 전환하는 것이 더 안전한 것으로 간주되었습니다.
권고는 패치 일정을 미리 제시했기 때문에 사람들이 자신의 인프라와 벤더 및 서비스 제공업체의 인프라를 파악할 시간을 주었습니다. 패치가 출시되자마자 필요한 경우 업그레이드가 이루어질 수 있도록 관련된 인프라 측면에서 필요한 모든 것을 계획하는 것이 아이디어였습니다.
어떻게 처리하시겠습니까?
이제 귀하가 서버에서 OpenSSL을 사용하는 회사의 엔지니어라고 가정해 보겠습니다. 권고가 떨어지자마자 어떤 버전의 라이브러리가 어디에서 사용되고 있는지(아직 실행 중인 경우 레거시 코드 포함) 파악한 다음 공급업체나 서비스 제공업체에 대해서도 동일한 내용을 파악해야 합니다.
이것은 SBOM 정말 도움이 될 수 있습니다. SBOM은 소프트웨어 BOM(Software Bill Of Materials)을 나타내며 특정 소프트웨어 제품을 구성하는 모든 구성 요소 및 소프트웨어 종속성의 목록입니다. SBOM에는 일반적으로 모든 소프트웨어 구성 요소의 이름 및 버전(이 내용의 내용 참조), 해당 소스 및 라이선스, 각 구성 요소와 관련된 알려진 취약성 또는 보안 문제와 같은 정보가 포함됩니다.
담당 엔지니어로서 각 제품에 대해 업데이트된 SBOM이 있는지 확인한 다음 OpenSSL을 사용하고 있는 위치와 사용 중인 버전을 찾는 것은 SBOM 파일에서 검색을 실행하는 간단한 문제였을 것입니다. . 또한 회사와 협력하고 있는 공급업체나 서비스 제공업체로부터 업데이트된 SBOM을 요청한 경우 그곳에서도 동일한 검색을 수행할 수 있습니다.
취약점이 3.0.0에서 3.0.6 사이의 버전에만 영향을 미친다는 말을 들었으므로 실행 중인 버전을 확인하여 어떤 애플리케이션을 제거하거나 새 패치인 3.0.7으로 업데이트해야 하는지 확인하기만 하면 됩니다. XNUMX.
OpenSSL을 사용하는 잘 알려진 운영 체제 및 엔터프라이즈 애플리케이션 목록이 얼마나 광범위한지 확인하려면 다음을 확인하세요. 명부 사람들이 얼마나 걱정해야 하는지 알 수 있도록 공공 서비스로 게시되었습니다.
증거 기반 보안 허브가 어떻게 도움이 될 수 있습니까?
광범위한 사이버 보안 환경을 포함하여 진화하는 사이버 보안 환경의 일부로 취약점, 우리는 현재 목격하고 있습니다 애플리케이션 보안이 소프트웨어 공급망 보안으로 진화. 이러한 문제를 해결하기 위해 새로운 세대의 도구와 기술이 개발되었습니다. 소프트웨어 개발 수명주기 및 소프트웨어 구성 요소의 신뢰성을 보증할 수 있는 증거 기반의 지속적인 코드 보안 보증 플랫폼을 제공함으로써 자동화된 도구 및 솔루션은 조직이 새로운 수준의 보안을 달성하도록 지원합니다. 종속성과 취약점을 지속적으로 매핑하면 패치가 출시될 때 패치를 수정하거나 적용하는 것이 더 간단해집니다.
학자 소프트웨어 공급망 보안 허브입니다. CI/CD 파이프라인을 통과하는 모든 빌드에 대해 증거를 수집하고 제시합니다. Scribe 솔루션의 목표는 소프트웨어 투명성을 강화하고 소프트웨어 개발자와 사용자 간의 신뢰를 조성하기 위한 EU 및 미국 규정과 모범 사례를 보다 쉽게 준수할 수 있도록 하는 것이었습니다. 이 플랫폼을 사용하면 포괄적인 SBOM은 물론 기타 보안 통찰력을 생성하고 공유할 수 있습니다. 또한 플랫폼은 현재 보고 있는 빌드가 NIST의 SSDF 프레임워크와 SLSA 레벨 3 요구 사항을 모두 준수하는지 확인할 수 있습니다. 각 빌드에 대한 SBOM이 포함된 증거 저장소가 있으므로 더 이상 어떤 라이브러리의 어떤 버전을 사용하고 있는지 파악하려고 헤맬 필요가 없습니다. 이제 이를 알아내는 것은 텍스트 문서에서 특정 문장을 찾는 것만큼 간단합니다.
마지막 말씀: 다음 번에 발생할 대규모 취약점 공개에 대비하십시오.
패치 3.0.7의 OpenSSL 프로젝트 스토리는 잠재적으로 심각한 취약점을 처리하는 방법에 대해 똑같이 중요한 두 가지 관점을 제공합니다.
영향을 받는 쪽(이러한 취약점으로 인해 잠재적으로 손상될 수 있는 회사 또는 프로젝트)으로부터 투명성을 제공했습니다. 해를 끼칠 수 있는 정보를 즉시 공개하지는 않지만, 문제를 인지하는 즉시 가능한 모든 정보를 공개합니다. 뿐만 아니라 문제에 대한 최대한 많은 정보와 함께 해결 일정도 제공합니다. 패치나 수정 사항이 존재하면 그들은 정확히 무엇이 잘못되었고 어떻게 잠재적으로 악용될 수 있는지 공개하는 데 주저하지 않았습니다. 이러한 투명성은 신뢰를 높여줍니다. 사용자와 고객은 회사가 수익이나 이사회에 대한 관심만큼 또는 적어도 자신에 대해 더 많은 관심을 갖고 있다는 것을 알고 느끼고 싶어합니다.
2014년 OpenSSL 프로젝트는 ''라는 치명적인 버그의 희생양이 되었습니다.심혈' – 공격자가 영향을 받는 서버에서 암호화 키 자료, 비밀번호 및 기타 민감한 정보와 같은 비밀을 얻을 수 있게 만드는 OpenSSL TLS/DTLS 구현의 심각한 결함입니다. Heartbleed는 OpenSSL의 심각한 취약점이 다양한 프로그램과 Linux 배포판에 영향을 미칠 수 있음을 보여주었습니다. 모든 취약한 시스템을 식별하고 수정하려고 노력하는 것은 보안 팀에게 수개월간 골치 아픈 일을 안겨주었습니다. 소프트웨어를 더 빠르고 간단하게 업데이트하고 패치할 수 있는 SBOM과 같은 도구를 구현하는 것은 모든 회사의 사이버 보안 팀에 도움이 될 것입니다.
문제 해결 측면에서 볼 때, 어떤 패키지를 사용하고 있는지 정확히 파악하는 것은 이러한 잠재적인 긴급 상황을 처리하는 데 필수적입니다. Log4J를 예로 들면, 일부 회사에서는 이 취약점이 발견된 지 XNUMX년이 넘도록 이 취약점의 영향을 받는지 여부를 파악하려고 여전히 노력하고 있습니다.
귀하가 걱정해야 할 것은 귀하의 소프트웨어 및 서버뿐만 아니라 귀하가 사용하는 제3자 공급업체 또는 귀하와 협력하는 모든 서비스 제공업체의 소프트웨어 및 서버, API 연결을 사용하는 경우에도 마찬가지입니다. 우리 사이에 신뢰의 그물을 구축해야 합니다. 그러한 신뢰는 가능한 한 확실한 증거에 의존해야 합니다. 자신의 SBOM과 거래 중인 모든 회사의 SBOM을 생성 및 추적하고, 해당 SBOM을 공유하고, 알게 된 악용 가능한 취약점을 알리고 수정하는 데 있어 선의를 보여주세요.
그러한 증거를 공유하는 것이 소셜 미디어에서 회사의 최신 PR을 공유하는 것만큼 흔한 세상이 되려면 우리 모두가 함께 노력해야 합니다. 이러한 신뢰가 없으면 우리 모두가 열심히 유지관리하기 위해 노력하는 상호 연결된 인프라를 무너뜨릴 차세대 중대한 취약점을 위한 발판을 마련하는 것일 뿐입니다.
이 콘텐츠는 소프트웨어 공급망 전반에 걸쳐 코드 아티팩트와 코드 개발 및 전달 프로세스에 최첨단 보안을 제공하는 선도적인 엔드투엔드 소프트웨어 공급망 보안 솔루션 제공업체인 Scribe Security에서 제공합니다. 자세히 알아보기.
관련 게시물
