본 글은 ModeZero에서 작성한 글과 ZwClose의 블로그 글을 바탕으로 작성된 글임을 밝힙니다.

실수가 두 번이면, 이거 의도적인 거 아니야? 올해만 벌써 두 번째다. 지난 2017년 5월쯤 HP사의 노트북에서 키로거(Keylogger)가 발견되었다. 키로그는 HP 오디오 드라이버에서 발견되었으며, HP노트북에서 키보드로 입력하는 모든 것을 모니터링하며 로그로 남겼다. 만약 공격자가 로그에 접근할 수 있다면, 사용자가 남긴 대화 내용, 사용자의 로그인 데이터 및 암호와 같은 중요한 정보도 노출될 수 있는 문제였다. HP는 해당 문제를 인정하고 패치 된 드라이버와 윈도우 업데이트를 통해 해당 취약점을 수정했다. 그리고 약 7개월이 지난 12월 10일경 HP 노트북에서 또 다른 키로거가 발견되었다. 아직 1년도 가지 않았는데, 같은 회사 제품의 노트북에서 키로거만 벌써 두건이다. 이번 키로그는 터치 패드 드라이버에서 발견되었으며, 이전과 마찬가지로 사용자의 데이터를 노출시키고 로그로 남겼다. 과연 어떻게 된 것인지, 무엇이 문제였는지 이에 관해 얘기해보자. 

HP(Hewlett-Packard)는 1939년 윌리엄 휴렛과 데이비드 팩커드가 공동으로 설립한 기업으로, 주로 개인용 컴퓨터와 프린터를 판매하고 서비스를 제공하는 회사다. HP는 다른 MS와 IBM 등 소위 말해 실리콘 밸리의 1세대 벤처기업이며, 유구한 역사를 자랑한다.[1] 컴퓨터와 관련한 제품 대부분을 만들며, 특히나 HP의 공학용 계산기도 많이 사용된다. 프린터 시장에서도 상당히 잘나가사 캐논, 앱손과 함께 3대 프린터 회사로도 꼽힌다.[2][3] HP의 노트북은 IDC 자료를 기준으로 2017년 2분기에 13.7백만 대를 출하시켜 점유율 22.8%로 1위를 차지했다.[4] HP는 국내에서 크게 빛을 발휘하고 있진 않지만, 세계 기준으로 주요 메이커에 꼽히며, 상당히 대중적으로 잘 알려져 있다. 문제는 이렇게 많은 고객을 보유하고 있는 회사의 제품에 문제가 생기면 그 피해가 무척이나 크다는 것이다. 따라서 개인적인 생각으로 큰 기업일수록 보안에 더 큰 관심을 가지고 사소한 문제라도 예민하게 처리해야하지 않을까 한다. 그런 의미로 HP에서 올해 5월에 한 번[5], 12월에 한 번[6], 벌써 두 차례 키로가 발견되었다는 것은 쉽게 넘어갈 문제는 아닌 듯 하다.

키로거는 Key와 Log의 합성어로, 키보드에서 누르는 모든 키를 모니터링하여 모든 키 스트로크를 기록하는 프로그램이다.[7] 일반적으로 악성코드 및 트로이 목마는 사용자의 정보나 신용 카드 번호, 암호 및 기타 개인 데이터를 도용하기 위해 이 기능을 사용한다. 특히나 PC방과 같은 공공장소에서 특별히 주의를 요구하는 프로그램이기도 하다. 즉 키로그 프로그램은 키보드에서 눌러지는 모든 글자를 저장하므로 키로그가 설치된 시스템에서 사용되는 모든 입력 값은 공격자에게 그대로 노출된다.

문제는 지난 5월 이러한 키로거가 세계 컴퓨터 점유율 1위인 HP사의 노트북에서 발견되었다는 것이다.[8] 당시 스위스 기반의 보안 회사인 Modzero의 보안연구원은 Windows Active Domain 인프라를 검토하는 도중 모든 키 입력을 감시하는 키로거가 발견하였다. 키로거는 HP 오디오 드라이버에서 발견되어, 사용자의 입력을 모니터링하며 로그로 남겼다. 당시 사건이 터졌을 때는 누구의 책임이냐가 이야기가 오가곤 했었다. 엄밀히 말하면 HP 사에서는 이 소프트웨어를 자체 장치용 드라이버 패키지로 제공되기 때문에 실상, 책임의 여부를 판단하기엔 쉽지 않은 것도 맞다. 그렇기 때문에, 실제로 HP 오디오 드라이버를 제작한 오디오 칩 제조업체인 커넥선트(Conexant)가 해당 소프트웨어를 개발하고 디지털 서명까지 했기 때문에 책임을 논하자면 커넥선트사의 책임이 더 클 수도 있엇던 것이다.

커넥선트는 미국 군수품 제조사에서 나오는 통합 회로 제조업체로, 주로 비디오 및 오디오 프로세싱 분야의 회로를 개발한다. 쉽게 말해, 그들은 오디오 칩용 드라이버를 개발하여 운영 체제가 하드웨어와 통신할 수 있도록 한다.[9] 오디오 하드웨어를 제어하는 부품은 컴퓨터 모델에 따라 다른데, HP 컴퓨터에 설계된 이 드라이버의 코드에는 모든 키보드 입력을 가로채고 처리하는 부분이 있었던 것이 문제가 되었다. 사실 이 기능은 특수 키를 눌렀는지 혹은 놓았는지를 인식하기 위한 기능이었지만 개발자는 여러 가지 진단 및 디버깅 기능을 도입하면서, 모든 키 입력을 디버깅 인터페이스를 통해 브로드캐스트하거나 하드 드라이브의 공용 디렉터리에 있는 로그 파일에 기록하는 키로거를 구현하게 된 것이다. 더욱이, 하드 디스크나 드라이브, SSD에 암호화를 하지 않은 채로 저장되기도 하였다. 결국 이 키로거는 2015년 연말부터 2년 동안 은밀하게 노트북에 숨어있으면서 사용자의 키 입력을 로그로 남기고 있었던 것이다. 문제의 키로거는 어느 누군가가 의도적으로 구현하였다기보단, 개발자의 과실로 보는 쪽이 더 많은 의견으로 악용되지는 않았을 것으로 추측했다. 해당 키로거는 아래의 주소에서 해당 파일이 보이면 삭제하는 것을 권고한다.

• C : \ Windows \ System32 \ MicTray64.exe
• C : \ Windows \ System32 \ MicTray.exe

이어서 12월 10일, HP에서는 또 다른 키로거가 발견되었는데, ZwClose라는 닉네임의 보안 연구원은 블로그 게시물을 통해 이를 알렸다.[10] 해당 키로거는 키보드의 백라이트를 제어하는 방법에 대해 분석하다 발견하게 되었고, 분석하는 도중 키로거를 가리키는 것처럼 보이는 흥미로운 문자열을 발견하면서 키로거에 대한 증거를 잡아냈다. 해당 키로거의 구성 요소가 기본값으로 비활성화되어 있어, 공격자가 일부러 활성화하지 않은 이상 큰 문제가 생기진 않을 테지만, 공격자는 충분히 이를 활성화하여 공격할 수 있었다. 이렇게 해서 만약 공격자가 키로거의 구성 요소를 활성화하면, 공격자는 사용자의 모든 키 입력을 기록하고 암호, 계정 정보 및 신용 카드 세부 정보를 포함하여 중요한 데이터를 도용할 수 있었다.

5월에 발견된 키로거는 오디오 드라이버에서 발견되었던 반면에 ZwClose가 찾은 키로거는 터치 패드 드라이버의 일부인 SynTp.sys파일에서 발견되었다. 기본적으로 키로거의 구성요소는 비활성화되어 제 기능을 하진 않지만, 만약 공격자가 UAC (User Account Control)를 우회하여 레지스트리 값을 조작한다면 내장된 키로거를 사용할 수 있는 오픈 도구로도 구현할 수 있었다. 현재 HP는 해당 키로거의 존재를 확인하고 제거하기 위한 업데이트를 한 상태다. 아래에는 기본적으로 비활성화되어 있는 키로거의 구성요소를 확인할 수 있는 레지스트리의 키 주소다.

• HKLM\Software\Synaptics\%ProductName%
• HKLM\Software\Synaptics\%ProductName%\Default

해당 업데이트는 HP 및 Windows Update 웹 사이트에서 다운로드 할 수 있으며, 영향을 받는 모델은 AP 웹 사이트에 나열되어 있다. 오디오 드라이버에서 발견된 키로거의 영향받는 컴퓨터가 대략 30개 정도였다면, 이번 키로거는 대충 어림짐작으로 봤을 때 약 500개에 다다랐다. 더불어, 현재 이에 대한 피해 상황으로 해당 드라이버 제조업체인 Synaptics가 따로 사용자에게 접근할 수 없음을 확인하고 다른 피해는 없었을 것으로 보고 있다.

두 번의 키로거 발견은 사용자들의 가슴을 쓸어내리게 하였다.[11] 1년에 두 번이나 발견된 키로거에 놀라고, 순순히 키로거의 존재를 인정하고 빠르게 대처하는 HP의 모습에서도 놀란 듯하다. 두 개의 키로거 발견에서는 공통점이 존재하는데 바로, 두 개 모두 HP가 구현한 것이 아닌 외부업체, 드라이버에서 발견되었다는 점이다. 이러한 점으로 봤을 때, 이 문제를 HP가 모두 떠안고 갈 것은 아니라는 것이다. 추가로 이들의 드라이버를 사용하고 있는 다른 제품에 한해서도 문제 여부를 확인하는 것이 좋을 것으로 보고 있다. 그렇다고 해서 HP가 완전히 책임이 없다는 것은 아니다. 드라이버는 어디까지나 하드웨어 맞춰서 수정을 가해야 하고 이 과정에서 디버그 코드는 제거되어야 했지만, HP는 그렇지 못하였으므로 문제에서 완전하게 회피할 수는 없을 것으로 본다. 발견된 두 개의 키로거가 다행히도 악의적으로 구현되어 적용되었기보다 개발자의 실수로 보여지는 면이 크지만, 이를 발견하지 못하고 한 해에 두 번이나 비슷한 사건이 나타났다는 것은 좀 더 1위의 면모가 떨어지지 않나 생각해보게 한다.