check 3d gpu
바로가기
메뉴로 이동
본문으로 이동

[전문가 기고] 황석훈 타이거팀 대표 “정적 분석 도구에 대한 단상”

정적분석 도구 사용시 주의점과 고려해야 할 사항들

길민권 기자 mkgil@dailysecu.com 2017년 04월 28일 금요일

▲ 황석훈 타이거팀 대표
▲ 황석훈 타이거팀 대표
한국에서는 2015년 1월부터 전 공공 SI사업에 대해 시큐어코딩을 의무화하고 이를 검증하도록 하였다. 뿐만 아니라 대부분의 대기업이나 일정 규모 이상의 업체들이 시큐어코딩을 의무화하는 개발 보안 프로세스 또는 내부지침 등을 구비하고 있다.

하지만 시큐어코딩을 검증하는 일은 절대 쉽지가 않다. 최소 몇 백본에서 몇 천본하는 소스코드를 모두 뒤져서 취약점을 찾아내는 일이라는 건 절대 쉽지 않는 일이기 때문이다. 필자는 필드에서 대한민국 최초로 정적분석 도구를 테스트했으며, 이후 다수의 소스코드 분석을 수행한 바 있다. 현재 정적분석도구 성능평가에 사용되는 코드도 개발했다. 또한 이를 수행했던 분들과도 의견을 나눠본 바 있다. 이를 기반으로 정적분석 도구 사용시 주의점과 고려해야 할 부분들을 애기하고자 한다.

코드를 직접 설계하고 개발하는 많은 개발자들이 여러 이유로 인해 보안 교육을 받고 있어 이해도가 높아진 것은 사실이나 모두가 그렇지는 않다. 또한 신규 개발자가 지속적으로 유입되는 시장에서 개발자가 보안을 충분히 이해하고 개발할 것이라는 기대는 다소 위험성이 있다. 뿐만 아니라 충분한 이해를 가지고 있다고 하더라도 개발 과정에서 설계상의 실수, 코딩상의 실수 및 버그가 발생할 가능성도 충분히 존재한다.

반면 코드를 검증하는 컨설턴트 또는 전문가는 어떤가. 현재 대부분의 업무 시스템은 웹으로 구성되어있고, 어플리케이션서버(WAS)를 통해서 기존 레거시 시스템과 연동을 하고 있다. 따라서 최근에 개발되고 검증되는 시스템들은 대부분 웹시스템이며 관련 랭귀지도 JAVA, C#, Python, Node.JS 등이 주류를 이룬다. 즉 코드를 검증할 전문가는 반드시 웹프로그래밍에 대해서 일정 수준 이상의 개발 경험 또는 이해도를 갖추고 있어야 한다. 그리고 관련 언어를 충분히 이해할 수 있어야 하는 것 역시 당연한 요구사항이다. 또한 웹해킹 기술에 대해서도 충분히 이해하고 있어야 하며, 이를 막는 방법에 대해서도 다양하고 체계적으로 이해를 가지고 있어야만 한다.

하지만 이러한 수준의 전문가는 매우 흔치 않다. 지금도 이해할 수는 없지만, 코드 한 줄 제대로 읽지 못하면서 소스코드 분석을 하는 경우도 본적이 있다. 그러다 보니 자연스럽게 업무 수행을 효과적으로 할 수 있도록 도구가 필요하고, 몇몇 벤더사에서 이러한 솔루션을 제공하고 있다.

문제는 일정 수준 이상의 전문가가 턱없이 부족하다 보니 도구에 대한 의존성이 심각할 정도로 높아지고 있다는 것이다. 도구는 도움을 주는 도구로만 사용되어야 하지만, 도구가 제시하는 보고서를 완벽한 결론이라고 논하는 전문가들로 인해 다수의 문제가 양산되고 있는 현실이다.

필자는 정적분석 도구를 사용할 때 주의해야 할 부분들에 대해서 아래와 같이 몇 가지를 언급하고자 한다.

◇첫번째 문제점은 정적분석 도구를 사용하는 시점이다.

개발보안 프로세스를 많은 기업들이 도입을 하면서 운영을 하기 위해서는 절차적으로 보안 검수라는 과정을 거치도록 하고 있다. 또한 공공기관의 경우 관련 규정에 의해 최종 감리 시점에 보안검토를 받도록 하고 있다. 하지만 최종 검수 단계에서 보안성 검토를 수행하는 것 자체는 문제가 없지만 이 과정을 정적분석 도구를 이용해 검증하는 것에는 문제가 있다.

정적분석 도구는 도구의 특징상 개발단계에서 개발자가 자신의 개발환경에 정적분석 도구를 함께 설치하고 컴파일시 마다 코드를 검증해 문제점을 사전에 확인 및 조치하는 방법으로 사용되어야 하는 도구다. 현재까지의 정적분석 도구는 모든 로직을 완벽하게 이해하기 어렵고, 취약할 가능성이 존재하는 코드사용이나 흐름을 위주로 분석하여 제시하기 때문이다. 이 말은 달리 해석하면 정적분석 과정에서 개발자의 판단이 일부 가미되지 않는다면 개발자의 코드에 대한 완벽한 검증을 할 수 없다는 말과도 같다.

대표적인 예가 바로 대부분의 도구에서 지원하는 예외처리이다. 만약 개발자가 SQL-Injection 공격을 차단하기 위해서 문자열 유효성 검증을 위한 함수를 만들었다고 하자. 현재의 정적분석 도구는 개발자가 직접 정의한 함수에 대한 판단을 제대로 수행하지 않는다. 따라서 해당 함수를 만들고 호출한다고 해서 안전하다고 판단하지 않는다. 개발자가 자신의 함수에 대해서 확신을 가지고 예외처리를 해줄 때에만 안전한 코드로 인식되는 것이다. 이러한 작업을 수행하려면 개발단계가 아니면 힘들다는 것이다.

즉 개발자의 개입은 개발과정에서 필수가 될 수밖에 없으며 정확한 개입을 위해서는 개발자가 공격에 대해서 충분히 이해를 하여야 한다는 것이 중요하다. 위에서 예를 든 SQL-Injection을 막기 위해서 시큐어코딩을 한다는 것이 단순히 입력된 문자열에 대한 검증만 하면 되는 것인가라는 질문을 하지 않을 수 없다. 기존에 알려진 바에 따르면 이러한 문자열 검증을 충분히 하지 않더라도 PreparedStatement 객체를 사용하여 코딩을 하면 안전하다고 알려져 있다. 이러한 경우에도 정적분석 도구에 대한 의견 반영을 어떻게 할 것인가에 대한 고민도 필요하다. 만약 유효성 검증을 수행한다면, 개발자의 코드가 충분히 유효성을 검증하는지에 대해서 개발자 스스로 판단할 수 있어야 한다. 하지만 개발자가 의도를 이해했지만 잘못된 코딩을 하고 예외처리를 해버렸다면 이는 취약점으로 남는다.

따라서 정적분석 도구를 충분히 잘 활용하여 개발된 경우라도 코드 검증시에는 반드시 예외 처리된 함수에 대한 검증을 별도로 수행해야 할 이유가 충분히 있다.

만약 정적분석 도구를 최종 검수단계에서 제대로 사용했다면 개발 과정에서 충분히 처리가 되었어야 하며 도구 검증 결과가 0개가 나와야 할 것이다. 즉 최종 검수단계의 목표는 단계가 나오는지 아닌지를 검증하는 단계가 되어야 한다는 것이다.

하지만 많은 공공기관 및 업체의 경우 해당 솔루션이 고가여서 구매를 꺼리는 경우도 있고, 구매하였다고 하더라도 잘 사용하지 않는 경우도 있다. 감리 또는 보안점검을 위해서 컨설팅 라이선스를 가지고 진행하게 되는 경우 아래 두번째의 문제점에 직면하게 된다.

◇두번째 문제점은 로그에 대한 분석 방법과 시간이다.

정적분석 도구를 제대로 사용함에 있어서 이 부분이 가장 어렵고 현재 나타나는 문제들 중 가장 심각한 문제이기도 하다. 일반적으로 개발시에 정적분석 도구를 사용하지 않고, 검수단계에서 정적분석를 통해서 소스 검증을 수행하는 경우에 주로 나타난다.

필자가 최초 정적분석 도구를 검증했던 기억에 따르면 2005년도 이기는 하지만 800본의 소스를 가지고 검증을 했는데, 약 2만건의 로그가 확인되었다. 이 로그를 완벽하게 다 이해하고 최종적으로 문제가 되는 취약점을 발견하는데 걸린 시간은 총 2주가 소요되었으며, 확인된 최종 취약점은 18개 정도였던 것으로 기억하고 있다.

물론 10년도 넘어 도구의 성능이나 기능적인 측면에서 많은 발전이 있었을 것이라고 생각하지만, 탐지 로그가 크게 줄어든 것 같지는 않다. 문제는 이러한 로그가 발생했을 경우 짧은 필터링 또는 예외처리 등 도구에서 지원하는 기능 등을 통해서 줄일 수 있는 분량은 제한적이다. 따라서 많은 양의 로그를 직접 따라가면서 확인하지 않으면 오탐과 정탐을 구분하는 것은 불가능하다. 정적분석 도구는 보안약점을 찾는 도구이지 취약점을 찾는 도구가 아니다. 즉 취약할 가능성이 존재하는 코드를 찾기 때문에 기본적으로 많은 양의 오탐을 내포할 수 밖에 없다. 또한 해당 코드가 개발자의 의도가 반영된 코드일 수도 있고 또는 도구가 잘못된 판단을 내릴 수도 있다.

하지만 정오탐을 구분하는 일은 쉽지 않다. 주어진 시간이 부족하기도 하지만 기본적으로 소스코드를 충분히 읽고 개발자의 의도와 환경을 이해할 만큼 개발 능력을 보유한 컨설턴트나 보안담당자가 흔치 않다는 것이 문제이다. 정오탐을 명확하게 구분하려면 탐지된 코드라인만 보는 것이 아니라 전후의 코드를 모두 읽어야 하며 필요할 경우 인클루드된 다른 모든 파일까지 읽어야 하는 경우도 발생할 수 있다.

또한 어떤 취약점의 경우에는 서비스 개발 상황에 따라서 취약점이 될 수도 있고 안될 수도 있는 경우가 있을 수 있다. 예를 들면, 파일업로드를 차단하기 위해서 가장 좋은 방법은 업로드 경로를 외부로 두는 것이지만, 내부에 두면서도 확장자 필터링을 구현해서 처리할 수도 있다. 바람직하지는 않지만 불가능하지는 않다. 하지만 필터링의 경우 IIS나 Apache의 버전에 따라서 우회 가능한 취약점들이 존재하기도 한다. 이럴 경우 전문가의 입장에서 어떤 판단을 내려야 하고 어떤 가이드를 제시하는 것이 바람직한 것인지 잘 판단해야 한다.

따라서 분석 전문가가 다양한 상황 등을 고려하여 충분히 분석 및 정리한 다음 개발자에게 넘겨서 조치를 취하도록 해야 하지만 이를 제대로 분석하지 않고 개발자에게 수백 개 이상의 로그를 전달한다면 아연실색하기 마련이다. 이미 개발은 완료된 상태이고 최종 단계에서 빨리 마치고 오픈해야 하는 입장에서 수백, 수천 개의 로그를 던진다면 놀라지 않을 개발자는 없을 것이라고 본다.

또한 해당 도구에 대한 이해가 부족한 개발자라면 더욱이 왜 그러한 상황이 발생했는지에 이해를 하려고 노력하기 보다는 분노에 가까운 짜증이 나지 않을까 싶기도 하다. 이는 개발자의 입장에서 보면 충분히 이해를 하고도 남음이 있다.

따라서 많은 상황에서 적당히 합의하고 상중하 취약점중 상만 처리하고 넘어가자는 식으로 타협을 보기도 한다. 하지만 이러한 점은 취약점을 모두 해소하겠다는 의지와는 다른 규정을 지키기 위함 이상으로 해석하기 어렵다고 본다.

만약 이러한 상황으로 도구를 사용했다면 반드시 전체 로그를 확인할 수 있을 시간을 보장하는 것이 매우 중요하며 최소 2주 이상의 시간은 보장해야 하지 않을까 한다.

◇세번째 문제점은 정적분석 도구는 정적분석만 한다는 점이다.

정적분석 도구는 소스코드를 따라가면서 입력된 값의 처리 과정을 분석하여 취약할 가능성을 제시하는 정적 분석 도구이다. 이 말은 달리하자면 동적으로 발생하는 다양한 공격등에 취약할 수 밖에 없다는 뜻이며 복잡한 업무 프로세스나 데이터 플로우에 대해서는 모두 이해하는 것이 쉽지 않다는 것이다.

따라서 현재까지 나와 있는 도구들은 데이터의 플로우에만 집중되어 있다 보니 웹 클라이언트쪽에서 데이터의 위변조 조작 등의 동적 공격 등에는 취약할 수 밖에 없다. 따라서 소스분석을 통해서 코드를 검증한다고 해서 소스코드 및 서비스가 모두 안전하다는 믿음은 잘못된 것이라는 것이다. 또한 정적분석 도구가 탐지하는 대부분의 방법이 패턴을 기반으로 하고 있기 때문에 해당 패턴을 벗어난 함수를 사용하거나 최신 코딩 기법 등은 탐지 대상에서 제외될 가능성도 배제할 수 없다.

◇네번째 문제점은 로그결과를 개발자에게 설명하고 개선을 돕는 일이다.

보안전문가 또는 정적분석 도구를 사용하는 컨설턴트는 그 결과를 개발자에게 충분히 이해 할만큼 잘 설명하고 있는가 이다. 문제점을 개선하는 방법은 매우 다양하다. 반드시 해당 코드를 수정해야만 고쳐지는 것은 아니다.

예를 들면 병원에서 암이 발견되었다고 하자. 이때 무조건 해당 암 조직을 메스로 떼어내는 것만이 능사는 아니라는 것이다. 환자의 몸상태 및 재정상태 등을 고려해서 최소의 비용으로 최대의 효과를 내는 방법이나 가장 확실한 방법 등을 고려해야 한다. 이러한 방법들 중에서 그에 맞는 수술방법이나 약물치료 등을 권해야 한다는 것이다. 또한 필요하다면 모든 방법을 설명하고 선택하도록 하는 것이 바람직하다.

또한 그러한 정도의 충분한 설명이 개발자가 충분히 이해할 만큼 개발자의 언어로써 이루어지고 있는지도 의문이다. 의사가 환자의 언어로 설명하지 않으면 어떻게 이해할 것인가라는 질문과 같은 이치다.

소위 전문가가 제시하는 대안들 중 상당수는 국내외에 보고되는 가이드 등을 참고하는 경우가 많다. 하지만 많은 가이드에서 제시하는 기술적 대처 방법이 잘못된 내용이 많고 이를 따라서 개발했다고 하더라도 기본적 대응 방법이 아니기 때문에 새로운 공격 기법에 다시 공격을 당하는 사례도 적지 않다.

국내에 소스코드 검증이 법제화되고 대중화되어 가는 일은 매우 반겨야 할 일임은 확실하다. 하지만 그러한 부분이 단순히 일부 업체에게만 이익이 되고 실제 고객에게 정확한 도움이 되지 못한다면 이것은 문제가 있는 것임이 자명하다.

마지막으로 정적분석 도구를 사용함에 있어서 반드시 검토되어야 할 부분들을 다시 정리하자면 다음과 같다.

-정적분석 도구를 언제 사용하는가?

-개발자가 정적분석 도구를 충분히 이해하고 사용하는 것인가?

-검증하는 전문가는 역량이 충분한가?

-검증하는 전문가에게 충분한 시간을 배정하였는가?

-검증 결과에 대해서 충분히 개발자가 이해할수 있도록 설명하고 있는가?

[글. 황석훈 타이거팀 대표 / h9430@tigerteam.kr]

※데일리시큐는 정보보안 분야 전문가들의 기술 기고 및 현 이슈에 대한 자신의 견해 글 등을 언제든 환영합니다!


<저작권자 © 데일리시큐, 무단 전재 및 재배포 금지>
목록