지난주, Qualys는 OpenSSH 클라이언트 버전 5,4 ~7,1의 취약점(CVE-2016–0777 및 0778)을 공개하는 ‘ ’ 보안 권고문 을 발표했습니다. 이러한 취약점이 악용될 경우, 개인 키 정보가 도난당할 수 있습니다. 이 취약점을 해결하기 위해 관리자는 OpenSSH를 버전 7,1p2 로 패치하거나, 기존 SSH 클라이언트를 구성하여 악용될 수 있는 기능을 비활성화할 수 있습니다.
규모에 상관없이 어떤 기업에서든 OpenSSH와 같은 소프트웨어의 취약한 버전을 발견하는 것은 큰 문제입니다. 대부분의 기업은 네트워크 내의 모든 엔드포인트를 파악할 수 있는 기본적인 역량조차 갖추지 못하고 있기 때문입니다. 프로세스 종료, 시스템 격리, 패치 배포 등 단일 시스템에서 수행하고 싶은 작업이 모든 엔드포인트에 걸쳐 이루어지려면 어려울 수 있는데, 이것이 바로 Tanium이 훌륭한 도구인 이유 중 하나입니다.
초기 연구
Qualys의 보도자료를 읽은 후, 우리는 해결 방법에 대한 추가 정보를 찾아보아야 했는데, 가급적이면 패치를 제공하는 측에서 제공하는 정보를 얻고자 했습니다. 이 분야의 권위자인 테오 드 라트(Theo de Raadt)는 에 게시한 글에서 , 문서화되지 않은 구성 지시어 인 UseRoaming no 를 통해 해당 버그가 표면화되는 것을 방지한다고 밝혔습니다. 언뜻 보기에는 해결 방법이 아주 간단해 보였습니다. 설정 파일에 항목을 추가하는 셸 스크립트를 간단히 작성하기만 하면 되는 것이었죠. 관련된 토론 에서, 구성 파일에 호스트 패턴이 정의되어 있는 경우 해당 구성을 구성 파일에 추가하는 작업이 실패할 수 있다는 점이 예리하게 지적되었습니다. 따라서 스크립트는 모든 호스트에 대한 구성 설정을 추가해야 합니다:
취약한 컴퓨터에 스크립트를 신속하게 배포하기
활성 구성 파일을 일괄적으로 수정하는 것은 이성적인 관리자라면 누구라도 불안해할 만한 일입니다. 이는 어느 정도의 주의와 만일의 경우를 대비한 대안을 마련하지 않고서는 해서는 안 될 일입니다. 파일을 수정한 경우, 한 대 또는 모든 시스템에서 변경 사항을 신속하게 되돌리려면 어떻게 해야 할까요? 먼저 기존 설정을 새 파일에 백업한 다음, ssh_config 파일에 UseRoaming no 수정 사항을 적용했습니다:
초기 테스트 과정에서 echo 명령어의 -e 플래그가 모든 시스템에서 지원되지 않는다는 사실을 확인하여, 이식성을 위해 $’’ 구문을 사용하기로 결정했습니다. 그래서 다음과 같이 명령어를 개선했습니다:
우리는 단일 시스템에서 다시 테스트를 진행했습니다. 다음은 기존 파일의 마지막 몇 줄, 명령줄을 통해 수동으로 수정 작업을 수행한 내용, 그리고 수정된 설정 파일의 마지막 몇 줄을 보여주는 이미지입니다:
우리는 수정 사항을 구성 파일에 여러 번 추가하는 극한 상황을 테스트한 결과, 중복이 발생하더라도 SSH 클라이언트가 계속 정상적으로 작동한다는 것을 확인했습니다. 운영 측면에서는 이는 훌륭한 안전 장치이지만, 개발 과정 후반에 정리해야 할 사항으로 기록해 두었습니다.
고장 안전 장치
가장 간단한 방법은 백업 파일을 config 파일 위에 덮어쓰는 것입니다. 이상적으로는 이런 조치를 취할 필요가 전혀 없겠지만, 이는 ‘미리 예방하는 것이 낫다’는 말처럼, 전사적으로 신속하게 문제를 해결해 나가는 과정에서 상당한 성과를 거두고 추가적인 확신을 심어줄 수 있는 조치입니다.
스크립트는 다음과 같이 간단합니다:
OpenSSH 취약점의 영향을 파악한다
수정 사항을 적용하고 제거하는 스크립트가 준비되었으니, 이제 적용 가능 여부를 판단할 또 다른 스크립트를 작성할 차례입니다. 이 스크립트를 Tanium 센서에 포함시켜, 전체 엔드포인트 네트워크에서 쿼리를 실행할 수 있도록 하겠습니다. 여러 테스트 결과 이 해결 방법이 긍정적인 효과를 보인 것으로 나타났으므로, 우리가 사용할 수 있는 가장 간단한 방법은 ssh_config 파일에 수정 사항을 적용했을 때 의도했던 내용이 포함되어 있는지 확인하는 것입니다.
이식성을 고려하여, 우리가 선택한 구현 방법은 awk 원라이너로, 특정 정규 표현식에 일치하는 부분들 사이에 있는 파일의 줄을 출력하는 방식입니다:
이는 3줄로 구성된 전체 수정 시퀀스가 파일에 기록된 경우에만 일치합니다. 저희 솔루션은 OpenSSH 버전과 무관하게 작동하기 때문에, “취약(Vulnerable)” 대신 “잠재적 취약(Potentially Vulnerable)”이라는 문자열을 반환하기로 결정했습니다. 버전에 구애받지 않고 더 광범위한 범위를 대상으로 함으로써, 연구자들이 OpenSSH의 동일한 로밍 기능에 대한 추가적인 취약점을 계속해서 밝혀내더라도 코드를 업데이트할 필요가 없을 것입니다. (로밍 기능은 실제로는 전혀 유용하지 않으므로, 설정을 통해 이 기능을 비활성화하면 운영에 부정적인 영향을 주지 않으면서 보안을 강화할 수 있습니다.) 일부 분들은 쉘쇼크(Shellshock)를 기억하실지 모르겠습니다. 당시 커뮤니티가 모든 문제를 제대로 해결하기까지는 몇 번의 시도와 소프트웨어 업데이트가 필요했습니다. 당사의 접근 방식은 SSH 클라이언트에서 이러한 결과가 재발하는 것을 방지합니다.
다음은 기본 ssh_config 파일을 대상으로 수행한 테스트 결과입니다:
그리고 이제 방금 막 제압했던 상대를 상대로:
이거 괜찮아 보이네요! 그런 다음 이 스크립트들을 “SSH 키 유출 우회 조치 상태”라고 명명할 Tanium 센서에 통합했습니다.
사용자별 SSH 설정 및 내용 다듬기
조사해 본 결과, 커뮤니티 내에서 사용자가 직접 ~/.ssh_config 파일을 설정했을 가능성이 있는 시스템에 대해 논의하는 사례를 많이 찾지 못했습니다. 이러한 설정은 전역 구성보다 우선 적용되므로, 해당 취약점을 해결하기 위해서는 이곳에서 수정 조치를 취해야 합니다. 이를 계기로, 홈 디렉토리도 순회하는 방식으로 콘텐츠를 한층 더 개선하게 되었습니다. 플랫폼 간의 차이 때문에, OS X와 *nix 계열을 모두 동등하게 지원하기 위해 결국 두 가지 버전의 스크립트를 만들게 되었습니다.
또한, 수정 사항을 적용하던 기존 스크립트의 로직을 개선하여, 수정 사항이 중복 적용되어 설정 파일이 불필요하게 커지는 것을 방지했습니다. 블로그 게시물에 깔끔하게 담기에는 너무 길지만, 그래도 코드와 주석을 합쳐 40 줄을 조금 넘는 분량입니다.
그 결과, *nix 및 OS X 시스템 전반에서 ‘잠재적 취약점’이 있는 시스템을 단 몇 초 만에 식별해 내는 솔루션을 개발했습니다. 만약 어떤 로컬 SSH 구성 파일에 기업 보안을 위한 완화 조치가 포함되어 있지 않다면, 사용자는 단 몇 분 만에 기업 내 일부 또는 모든 시스템에 해당 수정 사항을 적용하거나 원상 복구할 수 있습니다.
Tanium 플랫폼
Tanium은 시스템 수에 관계없이 모든 엔드포인트의 상태를 업계 유일의 실시간 가시성으로 파악할 수 있게 해주기 때문에 OpenSSH 취약점을 손쉽게 해결할 수 있게 해줍니다. 이 플랫폼은 본 게시물에서 설명한 접근 방식을 구현하는 데 있어 가장 빠르고 쉬운 방법입니다. 신뢰할 수 있는 출처의 데이터로 시작하여 스크립트를 개발하고, 테스트를 확대하며 개선한 뒤, 결국 플랫폼의 새로운 기능이 되는 것을 완전히 배포하면 됩니다.
의견이 있으시면 알려주시거나, 해당 콘텐츠를 귀사의 환경에 적용해 보고 싶으시다면 담당 기술 계정 관리자에게 문의해 주시기 바랍니다. Tanium에 대해 잘 모르시거나 더 자세히 알고 싶으시다면, 으로 문의하셔서 데모를 신청해 주시기 바랍니다.
로리 프렌더가스트, 수석 이사
피터 올슐레이거, 수석 이사
Tanium이 실제로 어떻게 작동하는지 궁금하신가요? 와 1:1 데모를 예약하거나 주간 웨비나에 참여해 보세요. 에서 개최될 예정인 행사()에서 Tanium 전문가들과 상담해 보세요.
