서드파티 라이브러리에 대한 공략법 연구가 끝이 없이 진행되고 있다. 최근에는 구글 SLO 생성기라는 라이브러리의 공략법이 개발되기도 했다. 이래 저래 개발자들의 보안 인식 제고와, 조직 차원에서의 패치 관리 절차 정립의 필요가 늘어나고 있다.

[보안뉴스 문가용 기자] 구글 SLO 생성기(Google SLO Generator)의 취약점의 익스플로잇 방법이 새롭게 개발됐다. 성공적인 익스플로잇 후에는 원격 코드 실행 공격이 가능하다고 한다. 공격자는 시스템에 접근해 악성 코드를 실행할 수 있게 된다. 이 때 공격자가 실행하는 코드는 신뢰할 만한 내부 네트워크에서부터 온 것처럼 보인다.

​

[이미지 = utoimage]

구글 SLO 생성기는 인기 높은 파이선 라이브러리 중 하나로, 웹 API 퍼포먼스를 계속해서 추적해 분석하고자 하는 엔지니어들 사이에서 널리 사용된다. 수많은 구글 서비스들에도 이 라이브러리가 적용되어 있다. 하지만 2021년 9월 이전 버전에서는 안전하지 않고 익스플로잇이 가능한 기능들이 존재했다.

보안 업체 비카리우스(Vicarius)의 CEO인 마이클 아스라프(Michael Assraf)는 이번에 발견된 익스플로잇 방법은 이전까지 전혀 알려지지 않았던 것이라고 말하며, “예전 버전의 라이브러리를 공격할 수 있는 획기적인 방법이 새롭게 발견된 것”이라고 설명했다. “현재 약 16만 7천 개의 애플리케이션들에서 구글 SLO 생성기 라이브러리가 사용되고 있는데, 이 중 취약한 버전이 어느 정도 비율을 차지하고 있는지는 아무도 모릅니다.”

취약한 버전을 사용하고 있지 않다면 이번에 발견된 새로운 익스플로잇 기법이 전혀 위협거리가 되지 않는다. 하지만 아스라프는 “개발자들 중 체계적으로 패치와 업데이트를 진행하는 사람들이 많지 않다”며 “위험 완화 대책을 활용하는 게 보통”이라고 지적한다. “패치 대신 임시적인 조치에 만족하는 개발자들이 상당히 많습니다. 그런 습관을 가진 개발자라면 이번 익스플로잇 기법 개발이 좋지 않은 소식이 됐겠죠.”

패치가 되지 않은 장비들은 늘 불안 요소

취약점은 공격자들에게 항상 좋은 먹잇감이었고 앞으로는 더할 것이다. 그 중에서도 외부에서의 침투를 가능하게 해 주는 취약점들의 인기는 상당하다. 그런데도 이번 주 보안 업체 레질리온(Rezilion)이 발표한 보고서에 의하면 소프트웨어와 인터넷에 직접 연결된 장비들에서 10년 넘은 취약점들이 곧잘 발견된다고 한다. “2010년과 2020년 사이에 발견된 취약점이 아직도 패치가 되지 않은 채 그대로 남아 있는 경우가 450만 건 이상입니다. 게다가 이런 취약점들을 찾는 스캔 행위도 적극 벌어지고 있습니다.”

레질리온의 취약점 전문가인 요탐 퍼칼(Yotam Perkal)은 “패치 안 된 취약점이 이렇게나 많은 데에는 여러 가지 이유가 있다”고 말한다. “일단 가장 큰 이유는 대부분 조직들이 취약점의 존재조차 파악하지 못하고 있다는 겁니다. 패치 소식은 듣는데, 그게 자신들 조직의 이야기라고 생각도 못하는 것이죠. 즉 내부 인프라에 대한 가시성을 확보하지 못했다는 얘기도 됩니다.”

그 다음 이유로 퍼칼은 “패치 자체가 까다로운 일이 될 수 있다”고 지적한다. “보통 패치라고 하면 시스템을 잠깐 멈춰야 합니다. 게다가 패치에 시간도 제법 걸리는 편이죠. 이게 장비 한 대 이야기라면 괜찮은데 수백 대에서 수천 대라면 얘기가 달라지겠죠. 패치는 사실 기업 입장에서는 대단히 자원 소모가 많은 일입니다. 게다가 패치를 적용했더니 호환성 문제가 새롭게 불거져 시스템이 마비되거나 고장나는 일도 흔하죠. 리스크 요인이 될 수 있다는 겁니다.”

패치되지 않은 취약점은 최악의 보안 문제

아스라프는 “패치되지 않은 취약점은 최악의 보안 문제”라고 주장한다. “패치를 하지 않는다 혹은 패치가 나오지 않는다는 문제는 어느 산업에나 공통으로 존재하며, 규모에 상관 없이 어느 기업에나 오랜 시간 존재해 왔으며 지금도 생생히 살아 있는 문제입니다. 큰 조직들일수록 취약점을 일일이 파악하기 힘들어 취약점이 그대로 방치될 확률이 높은데, 이 역시 패치되지 않은 취약점이 위험할 수밖에 없다는 뜻이 됩니다.”

게다가 매일 수십 개에서 수백 개씩 새로 나온다는 것도 보안 취약점이 가진 문제라고 그는 지적한다. “과장을 조금도 섞지 않고, 하루에 수십 개, 많게는 수백 개씩 취약점이 등록됩니다. 여기에 제로데이까지 더하면 그 수가 상상 이상이라는 것을 알 수 있죠. 그러니 패치는 점점 더 비싼 행위가 되고, 기업으로서는 더 많은 투자를 해야만 하는 보안 항목이 되어가고 있지요.”

그래서 아스라프는 “이 취약점 문제만 해결할 수 있다면 굉장히 많은 보안 사건을 미연에 방지하거나 해결할 수 있다는 뜻”이라고 설명을 이어간다. “취약점 해결에 가장 필요한 건 그 무엇보다 가시성 확보입니다. 네트워크, 자산, 인프라, 각 시스템의 취약점 정보를 모두 파악해서 늘 한 눈에 회사 전체를 볼 수 있어야 합니다. 어디가 이상하고, 어느 부분에 수리가 필요한지를 볼 수 없다면 당연히 고칠 수도 없습니다.”

그 다음으로 중요한 건 취약점의 우선순위를 정하는 과정이 도입되는 것이다. 위에서도 언급했지만 취약점의 수량 자체가 너무나 많고 시간이 걸리기 때문에 다 고칠 수는 없다. 가장 위험하고 가장 중요한 것들을 그 때 그 때 선정해 차례로 해결해나가야 한다. 우선순위의 기준은 하나인 채로 끝까지 유지될 수는 없고 상황에 따라 달라질 수 있는데, 그렇기 때문에 보안 담당자 혹은 패치 담당자의 우선 순위 정립 능력이 중요하다.

퍼칼은 “인지 제고가 반드시 필요한 요소”라고 주장한다. “사람은 자신이 인지하는 수준으로 움직이게 되어 있습니다. 패치가 되지 않은 취약점이 얼마나 위험한지를 깨닫게 된다면 자동으로 패치에 민감해집니다. 이는 맨위의 경영진으로부터 맨 아래 새내기 직원까지 모두 해당되는 이야기입니다. 더불어 보안 위생 및 실천 사항을 실천하도록 하는 데에도 인지 제고가 필요합니다.”

기업이라는 맥락에서 취약점 다루기

아스라프는 “기업의 현재 상황이라는 변수를 고려해서 패치를 관리해야 하는데, 이게 잘 되지 않는다”고 말한다. “CVSS 점수에 따라 시급한 패치를 결정하려는 경향이 있습니다. 하지만 아무리 CVSS 점수가 높아도, 우리 회사의 상황에서는 조금 패치를 미뤄도 되는 취약점일 수도 있습니다. 각 조직마다 고유의 디지털 환경이 있고, 고유의 사업 상황이 있는데, 일률적으로 우선순위를 정하기는 힘듭니다.”

그리고 패치의 자동 관리라는 기술을 도입하는 것도 고려해봄직한 일이라고 아스라프는 강조한다. “상황마다 패치의 순서가 달라진다고 하지만, 그래도 어느 정도는 큰 틀이 정해질 수 있습니다. 규칙이 수립된다는 건데요, 그럴 때 자동화 기술을 활용하여 패치를 관리하면 큰 도움이 됩니다. 사업 진행에 있어 가장 중요한 시스템에 제일 먼저 패치가 자동 적용되도록 한다든지 하면 취약점 관리가 훨씬 쉬워집니다.”

퍼칼은 현대 기업들 내부에서 실행되는 코드들이 대부분 서드파티 코드들이라는 것을 지적한다. “외부 업체 것을 사서 쓰는 경우도 있을 것이고, 오픈소스를 가져다가 직접 개발한 경우도 있겠죠. 이 두 가지 경우 중 하나 혹은 둘 다에 포함되는 코드의 수는 내부적으로 상당히 많을 것이고, 그러므로 모든 것을 다 패치하겠다고 접근하면 안 됩니다. 물리적으로 그럴 시간이 없을 겁니다. 그렇기에 자동화 기술의 사용이 점점 더 중요해지고 있습니다.”

3줄 요약

1. 인기 높은 파이선 라이브러리인 구글 SLO 생성기에서 취약점 익스플로잇 기법 발견됨.

2. 패치된 버전이 존재하나 개발자들이 패치를 잘 적용하지 않기 때문에 문제가 될 수 있음.

3. 패치의 어려움 존재하지만, 취약점을 그대로 놔두는 건 최악의 결과를 가져다 줄 수 있음.

[국제부 문가용 기자(globoan@boannews.com)]​ 

[출처 : 보안뉴스(https://www.boannews.com/media/view.asp?idx=108987&page=3&mkind=1&kind=1)]