이 글은 TouchEn nxKey: The keylogging anti-keylogger solution을 의역+기계번역한 글입니다. 읽을거리 판에도 올릴게요

https://palant(.)info/2023/01/09/touchen-nxkey-the-keylogging-anti-keylogger-solution/

요약있음.

 

나는 일주일 전에 한국의 소위 보안 응용 프로그램의 의무(https://palant(.)info/2023/01/02/south-koreas-online-security-dead-end/)에 대해 썼습니다.

여정은 RaonSecure의 TouchEn nxKey로 시작되었습니다.

해당 브라우저 확장 프로그램의 사용자 수는 1,000만 명 이상(Chrome 웹 스토어에서 표시되는 가장 많은 수)을 보유하고 있기 때문에 관심을 갖게 되었습니다.

실제 사용자 수가 상당히 높을 가능성이 높으며, 이 프로그램은 한국의 거의 모든 컴퓨터에 설치됩니다.

확장 프로그램을 너무 좋아해서가 아닙니다. 한국 사람들은 그 확장 프로그램을 완전히 싫어합니다.

별 5개 중 평균 1.3점을 받고 그것을 없애라는 말로 가득합니다.

그러나 한국에서 온라인 뱅킹 등의 것을 하려면 그것을 사용해야 합니다.

소프트웨어 설치를 강제하는 은행들은 이것이 보안을 향상시킨다 합니다.

그런데 대중은 이를 "맬웨어" 및 "키로거"라고 부릅니다.

나는 제품의 내부 작동을 분석하는 데 시간을 보냈고 후자는 진실에 매우 더 가깝다고 판단했습니다.

응용 프로그램에는 실제로 설계상 키 로깅 기능이 포함되어 있으며 이에 대한 접근 권한을 충분히 제한하지 않습니다.

또한 단순한 서비스 거부(DOS)에서 원격 코드 실행(RCE) 취약점에 이르기까지 다양한 버그가 있습니다.

전체적으로 제품에서 7개의 보안 취약점을 발견하고 보고했습니다.

배경

내가 한국의 상황을 개괄적으로 설명한 후(https://palant(.)info/2023/01/02/south-koreas-online-security-dead-end/), 사람들은 여러 한국 웹사이트에서 내 글에 대해 토론하기 시작했습니다.

특히 2005년 한국외환은행 해킹 사건[1] [2]에 대한 두 가지 뉴스에서 제가 놓치고 있던 중요한 정보를 제공한 댓글이 있습니다. 기술적인 세부 사항에 대해서는 가볍지만, 이것을 제가 이해한 내용으로 설명하려고 노력하겠습니다.

 

한국외환은행 해킹 사건은 2005년에 한국에서 큰 사건이었습니다. 사이버 범죄 조직은 원격 액세스 트로이 목마를 통해 사람들의 은행 계좌에서 5천만 원(당시 약 5만 달러)을 훔쳤습니다.

원격 액세스 트로이 목마를 이용하면 사용자의 로그인 자격 증명뿐만 아니라 보안 카드의 정보도 얻을 수 있습니다.

제가 아는 바로는 보안 카드는 뱅킹 트로이 목마에 의해 쉽게 손상될 수 있다는 이유로 2012년 유럽 연합에서 추방된 두 번째 요소 인증 방법인 인덱스 TAN과 유사했습니다.

 

사용자의 컴퓨터는 트로이 목마에 어떻게 감염되었을까요?

설명을 보면 이것은 브라우저로 감염된 웹사이트를 방문할 때 Drive-by Download(프로그램이 의도치 않게 다운되거나 사용자가 프로그램을 이해하지 못하도 다운하는 것)가 일어난 것 같습니다.

브라우저 취약점이 악용되었을 가능성이 있지만, 사용자가 속아서 응용 프로그램을 설치했을 수도 있습니다.

문제의 브라우저는 이름이 나와 있지 않지만, 그때 한국에서는 다른 브라우저를 사용하지 않았기 때문에 인터넷 익스플로러임이 확실합니다.

 

뉴스를 보면 사용자는 온라인 뱅킹 자격 증명(공인인증서)을 분실하거나 제공하지 않았으며 잘못한 것이 없다는 점을 강조합니다.

온라인 뱅킹의 무결성에 의문이 제기되고 있으며 은행은 충분한 보안 예방 조치를 시행하지 않는다는 비판을 받고 있습니다.

 

2005년에는 다른 나라에서도 이와 같은 사건이 많이 있었습니다. 이 문제가 완전히 제거되었다고 주장할 수는 없지만 오늘날에는 훨씬 덜 흔합니다. 또한 웹 브라우저는 훨씬 더 안전해졌습니다. 그리고 은행은 두 번째 요소를 개선했습니다. 적어도 유럽에서는 보통 거래하기 위해 2차 인증이 필요합니다. 그리고 인증 시 거래 세부 정보를 볼 수 있으므로 실수로 악의적인 행위자에게 송금을 방지할 수 습니다.

 

한국은 다른 방법을 선택했고 국민들은 빠른 결과를 요구했습니다. 두 번째 뉴스 기사에서는 범인을 검거합니다. 보안 응용 프로그램이 공격을 막을 수 있었지만, 그 사용이 필수는 아니었습니다. 은행은 추후 "해킹 방지" 애플리케이션을 제공하고 모든 사용자에게 의무적으로 설치하겠다고 합니다.

 

따라서 2006/2007년경에 TouchEn Key에 대한 첫 번째 언급이 있는 것은 우연이 아닐 것입니다.

응용 프로그램은 웹 페이지에 데이터를 입력할 때 중요한 데이터를 보호한다고 주장합니다.

이후 TouchEn nxKey는 Microsoft 이외의 브라우저를 지원하도록 개발되었으며, 이것이 제가 살펴본 것입니다.

 

TouchEn nxKey는 무엇을 합니까?

TouchEn nxKey의 모든 공개 기사는 키보드 입력을 암호화하여 키로거를 막기 위한 것이라고 말합니다.

이것이 내가 찾을 수 있는 모든 기술 정보입니다. 그래서 제가 직접 알아내야 했습니다.

 

TouchEn nxKey를 사용하는 웹사이트는 두 부분으로 구성된 nxKey SDK를 실행합니다.

웹사이트에서 실행되는 여러 JavaScript 코드와 일부 서버측 코드입니다.

작동 방식은 다음과 같습니다.

1. nxKey SDK를 사용하는 웹사이트에 암호 필드를 입력합니다.
2. nxKey SDK의 JavaScript 코드는 이를 감지하고 컴퓨터의 nxKey 애플리케이션에 알립니다.
3. nxKey 응용 프로그램은 Windows 커널에서 장치 드라이버를 활성화합니다.
4. 장치 드라이버는 이제 모든 키보드 입력을 가로챕니다. 키보드 입력을 시스템에서 처리하지 않고 nxKey 응용 프로그램에서 처리합니다.
5. nxKey 애플리케이션은 키보드 입력을 암호화하여 nxKey SDK의 JavaScript 코드로 보냅니다.
6. JavaScript 코드는 암호화된 데이터를 숨겨진 form 필드에 넣습니다. 실제 암호 필드에는 더미 텍스트만 전송됩니다.
7. 로그인 자격 증명 입력을 마치고 '로그인'을 클릭합니다.
8. 암호화된 키보드 입력은 다른 데이터와 함께 서버로 전송됩니다.
9. nxKey SDK의 서버측 부분은 암호를 해독하고 여기에서 일반 텍스트 암호를 찾습니다. 일반 로그인 절차가 시작됩니다.

위 내용 역자 개붕이 설명

1. 은행 사이트 들어가서 비번 입력
2. 은행 사이트에서 키보드 보안프로그램을 실행
3. 보안프로그램(드라이버로 실행됨): 윈도우야, 니가 카보드 입력 처리하지 마셈. 이거 내가 할 수 있으니까 내가 할꺼임
4. 윈도우: ㅇㅋ
5. 사용자: ID: dkdlel123, PW: q1w2e3r4!
6. 보안프로그램: 은행 사이트야, 받아. (암호화된 데이터)
7. 은행사이트에서 겉으로 보이지 않는 곳에 암호화된 키보드 입력이 들어감
8. 로그인 클릭(아이디 비번 서버로 보냄)
9. 서버에서 복호화&로그인 처리

따라서 이론은 이 웹사이트에 입력된 데이터를 기록하려는 키로거는 암호화된 데이터만 볼 수 있다는 것입니다. 웹 사이트에서 사용하는 공개 키(암호화 전용 키)는 볼 수 있지만 해당 개인 키(복호화 전용 키)는 없습니다. 암호를 해독할 방법이 없으므로 암호는 안전합니다.

 

예, 정말 좋은 이론입니다. 이론적으로는요.

 

역자: 여기부터 깊은 내용임. 읽다가 잠오면 건너뛰셈

웹사이트는 TouchEn nxKey와 어떻게 통신합니까?

웹 사이트는 특정한 프로그램이 컴퓨터에 설치되어 있는지 어떻게 알 수 있을까요?

그리고 웹사이트는 프로그램과 어떻게 소통할까요?

여기서 패러다임 전환이 진행 중인 것으로 보입니다.

원래 TouchEn nxKey는 브라우저 확장을 설치해야 했습니다. 해당 브라우저 확장 프로그램은 네이티브 메시징을 사용하여 웹 사이트에서 애플리케이션으로 요청을 전달했습니다. 그리고 응답을 웹페이지로 다시 전달했습니다.

 

그러나 브라우저 확장을 중간 다리로 사용하는 것은 더 이상 최신 기술이 아닙니다. 현재 접근 방식은 웹사이트에서 WebSockets API를 사용하여 애플리케이션과 직접 통신하는 것입니다.

브라우저 확장은 더 이상 필요하지 않습니다.

 

이 패러다임 전환이 정확히 언제 시작되었는지는 확실하지 않지만 아직 완료되지 않았습니다. 씨티은행과 같은 일부 웹사이트는 새로운 WebSocket 접근 방식만을 사용하지만 부산은행과 같은 다른 웹사이트는 여전히 브라우저 확장에만 의존하는 오래된 코드를 실행합니다.

 

이것은 사용자가 여전히 브라우저 확장을 설치해야 한다는 것 뿐만이 아닙니다. 소프트웨어가 설치되어 있음에도 불구하고 설치되지 않았다는 잦은 불만에 대해서도 설명합니다. 이러한 사용자는 WebSocket 통신을 지원하지 않는 이전 버전의 소프트웨어를 설치했습니다. 자동 업데이트가 없습니다. 일부 은행에서는 여전히 이러한 이전 버전을 다운로드할 수 있도록 제공하고 있기 때문에 제가 실수를 저지른 부분입니다.

 

역자: 구 버전은 A 방법을 지원함. 최신 버전은 A, B 방법을 지원함. C은행은 B 방법만 지원함. => 구 버전을 쓰면 C 은행에서 보안 프로그램이 깔려 있어도 보안프로그램이 없다는 오류

 

TouchEn 확장 프로그램을 악용하여 은행 웹사이트 공격

TouchEn 브라우저 확장은 정말 작으며 기능이 최소화됩니다. 여기서 많은 잘못을 저지르기는 어려울 것입니다. 그러나 코드를 살펴보면 다음과 같은 주석이 표시됩니다.

그래서 누군가가 끔찍하게 나쁜(매우 위험한) 방법을 설계했습니다. 그런 다음 그들은 이것이 eval() 없이 수행할 수 있다는 것을 깨달았거나 누군가가 그것을 지적했습니다.

그러나 나쁜 코드를 제거하는 대신 만일의 경우를 대비하여 보관했습니다.

솔직히 말해서 이것은 JavaScript, 보안 및 버전 제어에 대한 매우 나쁜 이해를 보여줍니다.

저만 그렇게 생각할 수도 있지만, 이 사람이 감독 없이 보안 제품용 코드를 작성하도록 놔두면 안됩니다.

 

역자: eval에 대한 MDN의 설명

경고: 주의: 문자열로부터 eval()을 실행하는 것은 엄청나게 위험합니다. eval()을 사용하면 해커가 위험한 코드를 사용할 수 있습니다. 아래에 eval을 절대 사용하지 말 것!을 확인하세요.

 

어느 쪽이든 위험한 eval() 호출은 이미 브라우저 확장에서 제거되었습니다. 은행 웹사이트에서 사용하는 nxKey SDK의 JavaScript 부분은 그리 많지 않지만 지금까지는 문제가 되지 않습니다. 그래도 코드 품질이 너무 나빠서 더 많은 문제가 있을 수밖에 없습니다.

 

그리고 콜백 메커니즘에서 그러한 문제를 발견했습니다. 웹사이트는 일부 이벤트에 등록하기 위해 애플리케이션에 setcallback 요청을 보낼 수 있습니다.

이러한 이벤트가 발생하면 응용 프로그램은 페이지에 등록된 콜백 함수를 호출하도록 확장에 지시합니다. 기본적으로 페이지의 모든 전역 함수는 이름으로 호출할 수 있습니다.

 

그러면 악의적인 웹 페이지가 다른 웹 페이지에 대한 콜백을 등록할 수 있습니까? 두 가지 장애물이 있습니다.

1. 대상 웹 페이지에는 id="setcallback"인 요소가 있어야 합니다.
2. 콜백은 특정 탭으로만 전달됩니다.

첫 번째 장애물은 기본적으로 nxKey SDK를 사용하는 웹사이트만 공격받을 수 있다는 것을 의미합니다.

브라우저 확장을 통해 통신할 때 필요한 요소를 생성합니다.

WebSocket을 통한 통신은 이 요소를 생성하지 않으므로 최신 nxKey SDK를 사용하는 웹사이트는 영향을 받지 않습니다.

 

두 번째 장애물은 현재 탭에 로드된 페이지(예: 프레임에 로드된 페이지)만 공격할 수 있음을 의미합니다.

 

그리고 이것은 놀라울 정도로 쉽게 밝혀졌습니다. 애플리케이션이 적절한 JSON 파서를 사용하여 들어오는 데이터를 처리하는 동안 응답은 sprintf_s()를 호출하여 생성됩니다. 이스케이프가 수행되지 않습니다. 따라서 일부 응답 속성을 조작하고 인용 부호를 추가하면 임의의 JSON 속성을 주입할 수 있습니다.

touchenex_nativecall({
  …
  id: 'something","x":"y'
  …
});

id 속성은 애플리케이션의 응답에 복사됩니다. 즉, 응답이 갑자기 x라는 새 JSON 속성을 가져옵니다. 이 취약점으로 인해 tabid에 대한 모든 값을 응답에 주입할 수 있습니다.

 

악성 페이지는 뱅킹 탭의 ID를 어떻게 압니까? 자체 탭 ID(TouchEn 확장이 유용하게 노출)를 사용하고 다른 탭 ID를 추측해 볼 수 있습니다.

또는 단순히 이 값을 비워 둘 수 있습니다. 이 경우 확장이 유용합니다.

 

 

따라서 tabid 값이 비어 있으면 현재 활성 탭으로 메시지를 전달합니다.

 

하나의 가능한 공격은 다음과 같습니다.

1. 새 탭에서 은행 웹사이트를 열면 활성 탭이 됩니다.
2. 페이지가 로드될 때까지 기다리면 id="setcallback" 요소가 표시됩니다.
3. "tabid":"" 및 "reply":"malicious payload"로 JSON 응답 속성을 덮어쓰면서 일부 함수에 대한 콜백을 설정하기 위해 TouchEn 확장을 통해 setcallback 메시지를 보냅니다.

콜백에 대한 첫 번째 호출은 즉시 발생합니다. 따라서 콜백 함수는 응답 속성의 악성 페이로드를 매개변수로 하여 은행 웹 사이트에서 호출됩니다.

 

거의 다 왔습니다. 가능한 콜백 함수는 eval일 수 있지만 마지막 장애물이 있습니다. TouchEn은 응답 속성을 콜백에 제공하기 전에 JSON.stringify()를 통해 전달합니다. 그래서 우리는 실제로 eval("\"malicious payload\"") 를 얻었고 이것은 아무것도 하지 않습니다.

 

반면에 대상 페이지에 jQuery가 있다면, $('"<img src=x onerror=alert(\'Hi,_this_is_JavaScript_code_running_on_\'+document.domain)>"')를 호출하면 예상 결과가 생성됩니다.

공격이 속임수에 성공하기 위해 jQuery를 기대하고 있습니까? 그렇지는 않지만 TouchEn nxKey를 사용하는 웹사이트는 TouchEn Transkey(온스크린 키보드)도 사용할 가능성이 높으며 이 웹사이트는 jQuery에 의존합니다. 전반적으로 한국의 모든 은행 사이트는 jQuery에 크게 의존하는 것 같습니다. 이는 좋지 않은 생각입니다.

 

그러나 nxKey SDK의 지정된 콜백인 update_callback은 JSON 문자열 데이터를 전달할 때 임의의 JavaScript 코드를 실행하는 데 악용될 수도 있습니다. update_callback('{"FaqMove":"javascript:alert(\'Hi, this is JavaScript code running on \'+document.domain)"}')을 호출하면 javascript:link로 리디렉션되고 임의의 코드를 부수적인 효과로 실행할 수 있습니다.

 

따라서 이 공격을 통해 악성 웹사이트는 TouchEn 확장에 의존하는 모든 웹사이트를 손상시킬 수 있습니다. 그리고 한국 은행의 어떤 "보안" 애플리케이션도 사용자에게 이 공격을 탐지하거나 방지하도록 강제하지 않습니다.

 

참고: TouchEn과 유사한 브라우저 확장

테스트를 시작했을 때 Chrome 웹 스토어에는 두 개의 TouchEn 확장 프로그램이 있었습니다. 덜 인기 있지만 대체로 동일한 확장이 제거되었습니다.

 

그러나 이것은 이야기의 끝이 아닙니다. INISAFE의 CrossWeb EX와 Smart Manager EX, iniLINE의 CrossWarpEX 등 거의 동일한 확장 프로그램을 3개 더 찾았습니다. CrossWeb EX는 그 중 가장 인기가 있으며 현재 400만 명 이상의 사용자가 설치했습니다. 이러한 확장 프로그램은 유사하게 웹사이트를 공격에 노출시킵니다.

 

처음 든 생각은 라온시큐어와 이니사프가 같은 계열사라는 것이었습니다. 그렇지 않은 것 같습니다.

 

그런데 iniLINE 소프트웨어 개발 회사에서 다음 페이지를 보았습니다.

여기에는 Initech과 RaonSecure가 협력사로 나열되어 있으므로 iniLINE이 이러한 문제가 있는 브라우저 확장 프로그램의 개발자인 것으로 보입니다. 또 다른 흥미로운 세부 사항은 맨 위에 있는 "주요 고객" 라인의 첫 번째 항목이 국방부입니다. 나는 그들의 방어 작업이 다른 협력사를 찾는 것보다는 더 나은 코드로 이어지기를 바랄 뿐입니다...

 

웹사이트에서 키로거 사용

이제 악성 웹사이트가 있다고 가정해 보겠습니다. 그리고 이 웹사이트가 TouchEn nxKey에 다음과 같이 알려준다고 가정해 보겠습니다. 그러면 해당 웹 사이트가 모든 키보드 입력을 받습니까?

예, 그럴 것입니다! 현재 어떤 브라우저 탭이 활성화되어 있는지 또는 브라우저 자체가 활성화되어 있는지 여부에 관계없이 사용자가 입력하는 모든 내용을 가져옵니다. nxKey 애플리케이션은 단순히 요청에 응할 뿐, 이 시점에서 의미가 있는지 여부는 확인하지 않습니다. 실제로 UAC(역자: 관리자 권한으로 실행 창, 사용자 권한이면 관리자 비밀번호 입력이 뜸)에 입력된 관리자 암호를 웹사이트에 제공하기도 합니다.

그러나 확실히 장애물이 있습니까? 네, 있습니다. 우선, 그러한 웹사이트에는 유효한 라이선스가 필요합니다. 애플리케이션 기능을 사용하기 전에 get_versions 호출에서 해당 라이선스를 전달해야 합니다.

 

이 특정 라이센스는 www.example.com에만 유효합니다. 따라서 www.example.com 웹사이트 또는 www.example.com이라고 주장하는 다른 웹사이트에서만 사용할 수 있습니다.

위 코드에서 origin 속성이 보이시나요? 예, TouchEn nxKey는 실제로 Origin HTTP 헤더 보다 임의로 조작할 수 있는 origin 속성을 신뢰합니다.

따라서 합법적으로 nxKey를 사용하여 일부 웹사이트에서 라이선스를 해제하고 해당 웹사이트라고 주장하는 것은 사소한 일입니다. 가짜 라이센스를 만들 필요조차 없습니다.

또 다른 장애물: 악성 웹사이트에서 받은 데이터가 암호화되지 않습니까? 어떻게 해독합니까? 개인 키가 알려진 다른 공개 키를 사용할 수 있어야 합니다. 그런 다음 알고리즘만 알면 데이터를 해독할 수 있습니다.

하지만, 그 중 어느 것도 필요하지 않습니다. TouchEn nxKey가 공개 키를 전혀 수신하지 않으면 암호화를 하지 않습니다! 그러면 웹 사이트에서 일반 텍스트로 키보드 입력을 수신합니다.

내 개념 증명 페이지(모든 HTML 상용구 포함 3kB 미만):

역자: 관리자 페이지, 즉 로그인 창에서 비번 입력해도 윈도우의 모든 보안을 우회하고 사용자 키보드 입력을 받아내서 비번 뜯어 갈 수 있음.

 

이 취약점의 심각성을 크게 줄이는 세 번째 장애물이 여전히 있습니다.

악의적인 웹 페이지가 가로채는 키보드 입력이 더 이상 목적지에 도달하지 못합니다.

사용자는 암호를 입력하기 시작하면 의심을 가지게 마련이지만 텍스트 필드에는 아무 것도 나타나지 않습니다.

nxKey 애플리케이션에 대한 나의 분석은 다음과 같은 방식으로만 작동한다고 제안합니다.

키보드 입력은 웹 페이지 또는 실제 대상에 도달하지만 둘 다에 도달하지는 않습니다.

애플리케이션 자체 공격

우리는 이미 이 제품의 JavaScript 코드를 작성한 사람이 능숙하지 않다는 것을 확인했습니다.

하지만 모든 전문가가 C++ 배경 지식을 가지고 있기 때문일까요?

개발자는 JavaScript를 떠나 모든 작업을 C++ 코드에 최대한 빨리 위임하려고 합니다.

 

슬프게도 이것은 제가 확인할 수 있는 의심이 아닙니다.

저는 바이너리 코드보다 JavaScript를 분석하는 데 훨씬 더 익숙하지만 응용 프로그램 자체도 비슷하게 문제로 가득 차 있는 것 같습니다.

실제로 C++보다는 C에 일반적인 접근 방식을 주로 사용합니다. 여기에는 많은 수동 메모리 관리가 있습니다.

나는 이미 그들의 sprintf_s() 사용에 대해 언급했습니다.

sprintf_s() 또는 strcpy_s()와 같은 함수에 대한 흥미로운 사실: 이들은 버퍼 오버플로를 일으키지 않는 sprintf() 또는 strcpy() 함수의 "메모리 안전" 버전이지만 여전히 사용하기 까다롭습니다. 충분히 큰 버퍼를 제공하지 못하면 유효하지 않은 매개변수 핸들러가 호출됩니다. 그리고 기본적으로 이것은 응용 프로그램을 충돌시킵니다.

nxKey 애플리케이션은 버퍼가 충분히 큰지 거의 확인하지 않습니다. 그리고 기본 동작도 변경하지 않습니다. 따라서 지나치게 큰 값을 보내면 대부분의 경우 프로그램이 충돌합니다. 충돌은 버퍼 오버플로보다 낫지만 충돌한 응용 프로그램은 더 이상 작업을 수행할 수 없습니다.

일반적인 결과: 온라인 뱅킹 로그인 양식이 올바르게 작동하는 것처럼 보이지만 이제 암호를 평문으로 수신합니다.

양식을 제출하면 오류 메시지가 표시될 때만 뭔가 잘못되었음을 알 수 있습니다. 이 취약점은 서비스 거부 공격을 가능하게 합니다.

또 다른 예: 모든 JSON 파서 중에서 nxKey 애플리케이션 개발자는 C로 작성된 파서를 선택했습니다. 뿐만 아니라 2014년 1월에 리포지토리를 가져와 업데이트하지 않았습니다. null 포인터 역참조가 2014년 6월에 수정되었나요? 예, 아직 있습니다. 따라서 JSON 데이터 대신 애플리케이션에 ](단일 닫는 대괄호)를 보내는 것만으로도 충돌이 발생합니다. 서비스 거부 공격을 허용하는 또 다른 취약점입니다.

그리고 그 WebSockets 서버 웹 사이트가 연결됩니까? OpenSSL을 사용합니다. 어떤 OpenSSL? 실제로 OpenSSL 1.0.2c입니다. 예, 여기 있는 보안 전문가들의 한숨이 들리는 것 같습니다. OpenSSL 1.0.2c는 출시된 지 7년이 되었습니다. 사실 1.0.2 브랜치에 대한 지원이 종료된 것은 3년 전인 2020년 1월 1일이었습니다. 여기에서 마지막 릴리스는 OpenSSL 1.0.2u였습니다. 즉, 버그와 보안 문제를 수정하는 18개의 추가 릴리스를 의미합니다. 어떤 수정 사항도 nxKey 애플리케이션에 적용되지 않았습니다.

역자: OpenSSL 1.0.2c는 7년 지났는데, 3년 전 마지막 지원 업데이트 조차 하지 않음. 2020년 기준 최소 18개의 알려진 버그와 보안 취약점이 있음...

 

충돌보다 더 흥미로운 것을 살펴보겠습니다. 위에서 언급한 애플리케이션 라이선스는 base64로 인코딩된 데이터입니다. 애플리케이션에서 이를 디코딩해야 합니다. 디코더 기능은 다음과 같습니다.

 

이 기능의 출처가 확실하지 않습니다. CycloneCRYPTO 라이브러리의 base64 디코더와 분명히 유사합니다. 그러나 CycloneCRYPTO는 미리 할당된 버퍼에 결과를 기록합니다. 따라서 nxKey 개발자가 직접 버퍼 할당 논리를 추가했을 수 있습니다.

그리고 그 논리에는 결함이 있습니다. input_len이 4의 배수라고 분명히 가정합니다. 그러나 abcd==와 같은 입력의 경우 실제 출력이 3바이트 크기임에도 불구하고 계산 결과 2바이트 버퍼가 할당됩니다.

1바이트 힙 오버플로를 악용할 수 있습니까? 예, 이 Project Zero 블로그 게시물 또는 Javier Jimenez의 이 기사에서 설명한 대로입니다. 그러나 그러한 익스플로잇을 작성하는 것은 내 기술 수준을 넘어선 것입니다.

대신 내 개념 증명 페이지는 무작위로 생성된 라이센스 문자열을 nxKey 응용 프로그램에 보냈습니다.

이것은 몇 초 만에 응용 프로그램을 충돌시키기에 충분했습니다.

디버거를 연결하면 메모리 손상의 분명한 증거가 나타납니다. 가짜 메모리 위치를 사용하여 데이터를 읽거나 쓰려고 시도했기 때문에 응용 프로그램이 충돌했습니다.

경우에 따라 이러한 메모리 위치는 내 웹사이트에서 제공한 데이터에서 가져왔습니다. 따라서 충분한 기술과 헌신을 갖춘 누군가가 원격 코드 실행을 위해 해당 취약점을 악용했을 수 있습니다.

최신 운영 체제에는 이와 같은 버퍼 오버플로를 코드 실행 취약성으로 전환하기 어렵게 만드는 메커니즘이 있습니다. 그러나 이러한 메커니즘은 실제로 사용되는 경우에만 도움이 됩니다. 그러나 nxKey 개발자는 애플리케이션이 로드한 두 개의 DLL에서 주소 공간 레이아웃 무작위화를 해제했고, 데이터 실행 방지는 4개의 DLL에서 해제했습니다.

도우미 응용 프로그램 악용

지금까지는 웹 기반 공격에 관한 것이었습니다. 그러나 맬웨어 응용 프로그램이 이미 시스템으로 관리하고 권한을 확장할 방법을 찾고 있는 시나리오는 어떻습니까? 그러한 맬웨어를 퇴치하는 데 도움이 되는 응용 프로그램의 경우 TouchEn nxKey는 놀라울 정도로 자체 기능을 제대로 유지하지 못합니다.

예를 들어 nxKey가 키보드 입력을 가로챌 때마다 시작되는 CKAgentNXE.exe 도우미 응용 프로그램이 있습니다.

목적: nxKey가 키를 처리하지 않으려는 경우 키가 올바른 대상 애플리케이션으로 전달되는지 확인합니다. 기본 응용 프로그램에서 사용하는 TKAppm.dll 라이브러리의 로직은 대략 다음과 같습니다.

nxKey 응용 프로그램은 사용자 권한으로 실행 중이므로 합리적인 모든 설정에서 CKAgentNXE.exe 실행으로 대체됩니다. 그리고 그 도우미 응용 프로그램은 명령 코드 2를 받으면 SendInput()을 호출합니다.

이 접근 방식의 이유가 무엇인지 이해하는 데 시간이 걸렸습니다. 결국 nxKey 애플리케이션과 CKAgentNXE.exe는 모두 동일한 권한 수준에서 실행됩니다. SendInput()을 호출하지 않는 이유는 무엇입니까? 이 간접 참조가 필요한 이유는 무엇입니까?

그러나 CKAgentNXE.exe는 IPC 개체에 대한 보안 설명자를 설정하여 무결성 수준이 낮음인 프로세스의 액세스를 허용합니다. 또한 설치 프로그램이 CKAgentNXE.exe의 자동 상승을 허용하기 위해 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy 아래에 레지스트리 항목을 생성한다는 것도 알게 되었습니다. 그리고 그것이 클릭한 곳입니다. 이것은 모두 Internet Explorer 샌드박스 때문입니다.

따라서 Internet Explorer에서 TouchEn Key가 ActiveX로 실행될 때 무결성 수준은 낮습니다. 이러한 방식으로 샌드박스를 사용하면 효과적으로 SendInput()을 사용할 수 없습니다. 이 제한은 Internet Explorer 샌드박스에서 CKAgentNXE.exe를 실행하고 자동으로 권한 상승을 허용함으로써 우회됩니다. 도우미 응용 프로그램이 실행되면 샌드박스 ActiveX 컨트롤이 연결되어 작업을 요청할 수 있습니다. SendInput()을 호출하는 것과 같습니다.

Internet Explorer 외부에서는 이 접근 방식이 의미가 없지만 TouchEn nxKey는 작업을 CKAgentNXE.exe에 위임하기도 합니다. 그리고 이것은 보안에 영향을 미칩니다.

무결성 수준 낮음에서 실행되는 맬웨어가 있다고 가정해 보겠습니다. 브라우저 취약점을 악용하여 거기에 도달했을 가능성이 있지만 지금은 해당 샌드박스에 갇혀 있습니다. 지금 무엇을 할 수 있습니까? CKAgentNXE.exe가 시작될 때까지 기다렸다가(조만간 발생할 수 있음) 이를 사용하여 탈출합니다!

내 개념 증명 응용 프로그램은 CKAgentNXE.exe에 Win 키, C, M, D 및 Enter 키와 같은 가짜 키보드 입력을 생성하도록 요청했습니다. 그 결과 중간 무결성 수준(기본값)으로 실행되는 명령줄 프롬프트가 열렸습니다. 실제 악성 애플리케이션은 샌드박스 외부에서 코드를 실행하기 위해 임의의 명령을 입력할 수 있습니다.

진정한 악성 응용 프로그램은 눈에 보이는 방식으로 작업을 수행하지 않습니다. CKAgentNXE.exe는 예를 들어 임의의 DLL을 모든 프로세스에 로드하는 명령 코드 5도 허용합니다. 그것이 시스템을 감염시키는 훨씬 좋은 방법이라고 생각하지 않습니까?

적어도 이번에는 필수 보안 애플리케이션 중 하나가 유용하게도 위험으로 지정했습니다.

 

맬웨어 작성자는 이 경고를 트리거하는 원인을 파악하고 우회할 수 있습니다. 또는 웹 소켓 연결을 시작하여 실제 은행 웹사이트처럼 AhnLab 애플리케이션을 활성화하지 않고도 CKAgentNXE.exe가 시작되도록 할 수 있습니다. 하지만 왜 귀찮게? 그것은 프롬프트 일 뿐이며 공격이 사전에 중지되지 않습니다. 사용자가 악성 애플리케이션을 제거하기 위해 클릭할 때는 이미 너무 늦었습니다. 공격은 이미 성공했습니다.

 

드라이버의 키로깅 기능에 직접 액세스

위에서 언급한 바와 같이 TouchEn nxKey 응용 프로그램(드라이버로부터 받은 키보드 입력을 암호화하는 응용 프로그램)은 사용자 권한으로 실행됩니다. 상위 애플리케이션이 아니며 특별한 권한이 없습니다. 그러면 드라이버의 기능(키보드 입력 처리)에 대한 액세스가 어떻게 제한됩니까?

 

물론 정답은 그렇지 않습니다. 시스템의 모든 응용 프로그램은 이 기능에 액세스할 수 있습니다. nxKey가 드라이버와 통신하는 방법만 알면 됩니다. 궁금한 점이 있다면 통신 프로토콜이 그다지 복잡하지 않다는 것입니다.

 

여기서 아이디어가 무엇인지 잘 모르겠습니다. 드라이버 통신을 수행하는 라이브러리인 TKAppm.dll은 Themida를 사용하여 난독화됩니다. Themida의 공급업체는 다음을 약속합니다.

Themida®는 SecureEngine® 보호 기술을 사용합니다. 이 보호 기술은 가장 높은 우선순위 수준에서 실행될 때 이전에는 볼 수 없었던 보호 기술을 구현하여 고급 소프트웨어 크래킹으로부터 애플리케이션을 보호합니다.

아마도 nxKey 개발자는 이것이 리버스 엔지니어링에 대한 충분한 보호를 제공할 것이라고 생각했을 것입니다. 그러나 런타임에 디버거를 연결하면 이미 해독된 TKAppm.dll 메모리를 저장하고 분석을 위해 결과를 Ghidra로 로드할 수 있습니다.

죄송합니다. 너무 늦었습니다. 나는 이미 필요한 것을 얻었습니다. 안전 모드에서 부팅할 때 응용 프로그램이 작동을 거부해도 소용이 없습니다.

어느 쪽이든 드라이버에 연결하고 시스템의 모든 키보드 입력을 가로채는 데 사용할 작은(70줄의 코드) 응용 프로그램을 작성할 수 있습니다. 권한 상승이 필요하지 않았고 사용자 권한으로 실행하면 충분했습니다. 그리고 웹 페이지와 달리 이 애플리케이션은 이 키보드 입력이 목적지로 전달되도록 할 수도 있으므로 사용자는 아무 것도 알아차리지 못합니다. 키로거를 만드는 것은 결코 쉬운 일이 아닙니다!

가장 좋은 점은 이 키로거가 nxKey 애플리케이션과 잘 작동된다는 것입니다. 따라서 nxKey는 키보드 입력을 수신하여 암호화하고 암호화된 데이터를 웹 사이트로 보냅니다. 그리고 내 작은 키로거도 일반 텍스트로 동일한 키보드 입력을 받습니다.

역자: 관리자 권한 없이 시스템의 모든 키를 받을 수 있음. 사용자는 알 방법이 없음. nxKey 랑도 잘 작동함(Touch En nxKey하고 키로거가 같이 작동해도 잘 됨)

참고: 드라이버 충돌

커널 드라이버를 개발할 때 알아야 할 것이 있습니다. 드라이버가 충돌하면 전체 시스템이 충돌합니다. 이것이 드라이버 코드가 절대 실패하지 않도록 특별히 확인해야 하는 이유입니다.

 

nxKey에서 사용하는 드라이버가 실패할 수 있습니까? 너무 자세히 보지는 않았지만 우연히 가능하다는 것을 발견했습니다. 응용 프로그램은 DeviceIoControl()을 사용하여 드라이버에 입력 버퍼에 대한 포인터를 요청합니다. 그리고 드라이버는 MmMapLockedPagesSpecifyCache()를 호출하여 이 포인터를 생성합니다.

 

예, 이는 이 입력 버퍼가 시스템의 모든 단일 애플리케이션에 표시됨을 의미합니다. 그러나 그것은 주요 문제가 아닙니다. 오히려 애플리케이션이 포인터를 다시 요청하면 어떻게 될까요? 음, 드라이버는 단순히 다른 MmMapLockedPagesSpecifyCache() 호출을 수행합니다.

 

루프에서 이 작업을 약 20초 후에 전체 가상 주소 공간이 고갈되고 MmMapLockedPagesSpecifyCache()가 NULL을 반환합니다. 드라이버는 반환 값을 확인하지 않고 충돌합니다. 운영 체제가 자동으로 재부팅됩니다.

 

이 문제는 제가 말할 수 있는 바에 따르면 악용할 수 없지만(참고: 저는 바이너리 악용에 관한 전문가가 아닙니다) 여전히 다소 심각합니다.

 

역자: 드라이버 크래시 나면, 윈도 블루스크린 뜸. TouchEn nxKey에서 쓰는 드라이버가 충돌할 가능성이 있다는 내용임.

 

고쳐질까요?

일반적으로 취약점을 공개하면 이미 수정된 상태입니다. 이번에는 아쉽게도 그렇지 않습니다. 내가 말할 수 있는 한, 지금까지 어떤 문제도 해결되지 않았습니다. 벤더가 언제 이러한 문제를 해결할 계획인지 모르겠습니다. 또한 특히 은행이 현재 릴리스보다 적어도 세 가지 버전의 빌드를 이미 배포하고 있다는 점을 감안할 때 그들이 사용자에게 업데이트를 어떻게 푸시할 계획인지 모르겠습니다. 자동 업데이트 기능이 없다는 것을 기억하십시오.

이러한 문제를 보고하는 것조차 복잡했습니다. 라온시큐어는 보안에 특화되어 있음에도 불구하고 어떠한 종류의 보안 연락처도 기재하지 않습니다. 실제로 라온시큐어는 서울에 있는 전화번호 외에는 어떤 연락처도 기재하지 않는다. 아니요, 한국에 전화해서 거기에 영어하는 사람이 있는지 묻지 않겠습니다.

다행스럽게도 KrCERT는 특히 외국인 시민이 사용할 수 있는 취약성 보고서 양식을 제공합니다. 이 양식은 자주 오류가 발생하고 모든 내용을 다시 입력해야 하며 일부 보고서는 뚜렷한 이유 없이 웹 방화벽에 걸리지만 적어도 보안 연락처를 찾는 부담은 다른 사람에게 있습니다.

2022년 10월 4일에 KrCERT에 모든 취약점을 보고했습니다. 여전히 일부 RaonSecure 임원에게 직접 연락을 시도했지만 응답을 받지 못했습니다. 적어도 KrCERT는 약 2주 후에 내 보고서를 RaonSecure에 전달했음을 확인했습니다. 그들은 또한 RaonSecure가 내 이메일 주소를 요청했고 나에게 연락하기를 원한다고 언급했습니다. 그들은 결코하지 않았습니다.

그리고 그게 다야. 90일 공시 기한은 일주일 전이었다. TouchEn nxKey 1.0.0.78은 제가 이러한 취약점을 보고한 날인 2022년 10월 4일에 릴리스된 것으로 보입니다. 작성 당시에는 최신 릴리스이며 여기에 설명된 모든 취약점이 여전히 존재합니다. 수백만 명이 사용하는 TouchEn 브라우저 확장 프로그램의 최신 버전은 2018년 1월에 출시된 지 아직 5년이 되었습니다.

참고: 정보 유출

그들이 수정 작업을 하고 있다는 것을 어떻게 알 수 있습니까? 글쎄요, 이전에 저에게 일어난 적이 없는 일 덕분에 마감일 이전에 제 개념 증명(취약점에 대한 거의 완전한 익스플로잇을 의미)이 유출되었습니다.

보세요, 저는 보고서에 직접 파일을 첨부하곤 했습니다. 그러나 이러한 첨부 파일은 과도한 보안 소프트웨어에 의해 제거되거나 파괴되는 경우가 많습니다. 그래서 이제 문제를 시연하는 데 필요한 모든 파일을 내 서버에 업로드합니다. 내 서버에 대한 링크는 항상 작동합니다.

추가 이점: 의사 소통을 하지 않는 회사의 경우에도 벤더가 개념 증명에 액세스했는지, 즉 내 보고서가 누구에게 전달되었는지 로그에서 확인할 수 있습니다.

며칠 전에 TouchEn nxKey 파일에 대한 액세스 로그를 확인했습니다. 그리고 즉시 Googlebot을 보았습니다.

아니나 다를까: 이 파일들은 결국 Google 색인에 나열되었습니다.

이제 임의의 폴더 이름을 사용하므로 추측할 수 없습니다. 그리고 벤더하고만 링크를 공유했습니다. 따라서 공급업체는 익스플로잇에 대한 공개적으로 볼 수 있는 링크를 어딘가에 게시했을 것입니다.

그리고 그것이 실제로 그들이 한 일입니다. 공개적으로 표시되고 Google에서 색인을 생성한 개발 서버를 찾았습니다. 이 서버는 원래 내 개념 증명 페이지에 연결되어 있는 것 같습니다. 내가 그것을 발견했을 때 그것은 공급업체의 수정된 복사본을 대신 호스팅하고 있었습니다.

Googlebot의 첫 번째 요청은 2022년 10월 17일이었습니다. 따라서 이러한 취약점은 공개 마감일 2개월 이상 전에 Google 검색을 통해 찾을 수 있다고 가정해야 합니다. 그들은 여러 번 액세스되었으며 제품 개발자만 그랬는지 여부를 말하기 어렵습니다.

이 문제를 보고한 후 개발 서버는 공용 인터넷에서 즉시 사라졌습니다. 그래도 보안에 민감한 정보를 이렇게 부주의하게 다루는 것은 이전에 본 적이 없습니다.

nxKey 기본개념이 작동할까요?

TouchEn nxKey 애플리케이션에서 많은 취약점이 발견되었습니다. 키로거와 싸우려고 시도함으로써 nxKey 개발자는 완벽한 키로깅 도구 세트를 구축했지만 이에 대한 액세스를 제한하지 못했습니다. 하지만 아이디어가 멋지죠? 제대로 구축되면 실제로 유용한 보안 도구가 될 수 있습니까?

 

질문: 보호되는 키로거는 어떤 수준에서 실행됩니까? 내가 보는 방식에는 네 가지 옵션이 있습니다.

1. 브라우저. 따라서 일부 악성 JavaScript 코드가 온라인 뱅킹 페이지에서 실행되어 암호를 캡처하려고 시도합니다. 이 코드는 페이지가 nxKey를 활성화하는 것을 사소하게 중지할 수 있습니다.
2. 시스템에서 사용자 권한. 이 권한 수준은 예를 들어 사용자 권한으로 실행 중인 CrossEXService.exe 프로세스를 종료하기에 충분합니다. 이렇게 하면 서비스 거부 공격과 동일한 결과를 얻을 수 있으며 보호가 효과적으로 비활성화됩니다.
3. 시스템에서 관리자 권한. 실제로 nxKey 드라이버를 언로드하고 트로이 목마 복사본으로 교체할 수 있는 충분한 권한입니다.
4. 하드웨어. 게임 오버, 이에 대한 소프트웨어 기반 솔루션을 시도하는 행운을 빕니다.

따라서 nxKey가 제공하는 보호 기능이 무엇이든 nxKey와 그 기능을 알지 못하는 공격자에게 의존합니다. 일반 공격은 차단될 수 있지만 특히 한국 은행이나 정부 기관을 대상으로 하는 공격에는 효과적이지 않을 수 있습니다.

이 네 가지 수준 중 2번은 수정이 가능할 수 있습니다. 응용 프로그램 CrossEXService.exe를 관리자 권한으로 실행하도록 만들 수 있습니다. 이렇게 하면 맬웨어가 이 프로세스를 방해하는 것을 방지할 수 있습니다. 그러나이 보호의 효과는 여전히 사용자의 브라우저에 들어갈 수 없는 맬웨어에 따라 달라집니다.

이 개념이 다른 수준에서 작동하는 맬웨어에 대해 안정적으로 작동하도록 만드는 방법을 알 수 없습니다.

역자: (사실상 의미 없다는 내용)

역자의 글

재미있는글 이였음.

내 생각에는 이 모든 만악의 근원인 보안프로그램 자동 설치 프로그램인 Veraport도 취약점 몇 나올것 같음.

그나마 다행인건 Veraport는 CMS 프로토콜로 서명된 메시지를 확인한다는 것 정도?

 

요약

1. XSS 공격 취약점 발견(이 취약점 범인의 고객사 목록에 국방부 있음...)
2. 그냥 아무 웹사이트에서 키로깅 가능(입력이 안되기 때문에 사용자가 알아차리기 쉬움)
3. Helper 프로그램을 악용하면 임의의 명령을 아무 권한이 없는 상태에서 내릴 수 있음(권한상승취약점)
4. 일반 프로그램이 권한 없이 사용자 모르게 모든 프로그램의 키로깅 가능
5. 드라이버에 버그 있어서 블루스크린 띄울 가능성있음.
6. 근데 90일이 지나도록 안고침(보고 이후 90일 지나면 취약점 공개해도 됨).

승희님 .info좀 풀어주세요 ㅠㅠ