Broken Code (window31)

보안검수의 종류를 말할 때, 화이트박스 분석, 그레이박스 분석, 블랙박스 분석 등, 작업 깊이에 따라 색깔로 분류한 정의를 들어보신 적 있으실겁니다. 물론 가장 짙은 색인 블랙박스는 아무래도 정보가 전혀 없는 어두운 공간 안에서 진행한다는 뜻으로 칭해진 의미일거고, 그레이박스에서 화이트박스까지, 색깔이 점점 옅어짐에 따라 박스의 내부를 좀더 자세히 들여다 볼 수 있다는 얘기로 이같은 분류법이 지어진 것 같습니다.

이런 정의를 인터넷에서 흔히 찾아서 나올 수 있는 단순히 용어의 수준에서 그치지 않고 좀더 실무나 실전에 가깝게 정의해서 분석을 실제로 진행하는 검수가의 시각에서 바라보며 제맘대로 한번 작성해 보도록 하겠습니다.

1. Black Box Analysis

데이터와 정보가 아무 것도 없는 채, 일반 유저와 마찬가지 상태에서 보안검수를 하는 것을 말합니다. 정보가 부족한 상태에서 분석을 하는 것이므로 기본적으로는 애플리케이션의 정상적인 가동 상태, 그리고 매우 쉽게 파악 가능한 패턴화 되어 있는 취약점 까지만 진단 가능한 경우가 대부분입니다.

블랙박스 상태에서는 아무래도 개발팀에서 처리한 내용에 대해 어떠한 단서도 얻지 못하는 경우가 많으므로 어떻게 보면 검수 영역에 한계가 있다는 것이 당연하다고 생각할 수 있지만 예외적으로 검수가의 능력에 따라 블랙박스 상태에서도 충분한 데이터를 얻어오는 경우도 있습니다. 하지만 그 경우에는 내부 코드를 해킹이나 리버싱으로 샅샅히 훑어야 하는 작업이 선행되므로 아무래도 시간이 엄청 많이 걸릴 수밖에 없습니다(오리지날 소스를 보거나 아니면 개발자에게 한번 물어보기라도 하면 될 일을 직접 분석하고 있으니 시간이 걸리는 것은 당연할 수밖에).

개인적으로 생각하기에 블랙박스 검수단계는 두가지 타입의 사람이 검수를 한다고 생각합니다.

1) 실력이 아주 뛰어남 (개발팀에게 묻지 않아도 스스로 데이터를 다 캐취해냄)
2) 실력이 아주 보잘 것 없음 (그냥 프로그램을 한번 실행해 보고, “어 별일없군 끝”). 

이렇게 극과 극이 존재한다고 생각하며, 첫번째와 두번째 모두 해당되지 않는 “중간 실력”을 보유하고 있는 자는 본인의 한계를 알고 있기 때문에 아예 그레이박스 단계에서 분석을 시작하면 시작했지, 두가지 케이스에는 해당하는 작업은 잘 하지 않는다고 생각합니다. 사실 저라도 그렇습니다. 언제 저걸 일일히 다 하고 있어요 ;;; (물론 예외적으로 직접 다 해야할 때도 있지만 ;; ) 중간 실력자 타입은 무언가의 근거확립이나 브레이크 포인트를 설정한 이후에 검수를 하기 때문에 블랙박스 검수를 할 경우에는 알려진 유형적 취약점 정도만 기계적으로 대입해 보고 그 수준에서 작업을 마무리 하는 것 같습니다.

2. Gray Box Analysis

부분적인 소스 코드나 알고리즘 등 여러 가지 구조나 정보를 사전에 얻고 보안 검수를 진행하는 것을 말합니다. 아무래도 근거나 데이터가 있으므로 블랙박스 상태에서보다는 훨씬 효율적인 보안 검수가 가능하게 되겠죠.

또, 부분적으로 여러 장벽을 제거하거나 불필요한 단계를 거치지 않고 검수를 진행할 수 있습니다. 예를 들어 보안 모듈이나 기타 서드파티 툴이 여러 겹으로 보호하고 있을 때에 블랙박스 상태라면 그것을 검수가 자력으로 걷어낸 상태에서 검수를 하는 등 어쨌든 검수할 있는 형태로 분류시키는 작업을 누군가의 도움 없이 진행해야만 합니다, 하지만 개발팀의 협조가 가능한 그레이박스 단계라면 필요한 코드만 적시적소에 제거한 상태로 검수할 수도 있고, 소스 레벨 단계에서도 여러 가지를 시도해 볼 수도 있습니다. 아주 편리하죠.

다만 여러가지 개발 데이터를 받는 것이기 때문에 검수가의 개발 스펙이 떨어지면 걍 블랙박스 검수를 하느니 보다 못한 꼴이 될 수도 있습니다. 괜히 오바해서 그레이박스 검수를 하다가 개발자와 대화도 되지 않아서 개쪽을 먹기도 합니다. 따라서 개발팀과의 커뮤니케이션이 매우 중요한 단계가 됩니다.
 
또한 검수가의 경험 역시 중요시된다고 할 수 있습니다. 왜냐하면 개발팀에게 무언가를 받긴 받아야 하는데, 개발팀에서는 어떤 코드나 어떤 부분이 취약한 지 모르기 때문에 사실 검수가에게 뭘 물어봐야 할지 뭐를 주어야 할지도 모르는 경우가 있기 때문입니다. 따라서 검수가가 직접 필요한 데이터나 코드를 개발팀에 요청해야 하는데 당연히 적절한 위치나 코드, 변형된 모듈 등을 선정할 수 있는 실력이 필요하며, 개발팀과 협조하여 진행해 나가야 할 것을 능수능란하게 리드할 수 있어야 합니다.

해킹을 많이 당해본 개발자의 경우 경험 부족이나 능력이 떨어지는 검수가를 이 단계에서 한눈에 알아봅니다. 따라서 당연히 단지 툴 실행이나 얄팍한 테크닉에 의지하고 코드는 거의 볼 줄 모르는 사이비 보안검수가는 이 단계에서부터는 활동할 수 없습니다. 하지만 협력이 잘된다면, 아주 퀄리티 높은 보안 처리가 아웃풋으로 나올 수 있습니다.

3. White Box Analysis

이건 내일 마저 작성 해보겠습니다. 너무 길어져서 몰입력이 떨어질 것 같은 생각이 드네요 :)
제일 할말도 많은 화이트박스 검수 쪽이므로 제대로 다시 마음잡고 한편 작성해 보겠습니다 :p


window31.