윈도우 네트워크 수준 인증(Network Level Authentication)

• 1. RDP 활성화

• 2. 네트워크 수준 인증(Network Leven Authentication)

• 3. 발생할 수 있는 취약점

• 4. 취약점 발생 경로

• 5. 취약점 탐지 및 방지

• 6. 왜 CMD가 실행이 될까?

• 7. 왜 SYSTEM 권한이 떨어질까?

• 8. 여담

• 9. 해당 오류가 자세히 정리된 글

 윈도우환경은 RDP(Remote Desktop Protocol)을 사용한 원격접속 기능을 아주 네이티브하게 지원을 한다. 그래서 리눅스나 맥OS 같은 다른 운영체제보다 좀더 깔끔하다는 느낌을 받을 수 있다.

 기본적으로는 비 활성화 되어있지만, 시스템 설정에서 활성화 함으로써 손쉽게 원격 데스크톱을 사용할 수 있다는 장점 또한 있다.

 이번 글에서는 원격 데스크톱 하위 기능 중에 Network Level Authentication(NLA) 이라는 기능에 대해서 한번 얘기해보고자 한다.

 

1. RDP 활성화

 윈도우(10 이상. 윈도우 7은 지원기간이 끝났고, 8이나 8.1은 사용할 별 다른 필요성을 못느끼기 때문에 제외)에서는 별 다른 어플리케이션 설치 없이 아주 네이티브하게 RDP를 사용할 수 있다. 바로 다음과 같이 설정할 수 있다.

윈도우 10 원격 데스크톱 활성화

 

윈도우 11 원격 데스크톱 활성화

 

 두 운영체제의 차이라면 윈도우 10에서 내컴퓨터의 속성 탭이 윈도우 11에서는 설정-시스템 탭으로 옮겨갔다는 것이다.

 원격 데스크톱을 활성화 하면 그 밑에 '디바이스에서 네트워크 수준 인증을 사용하여 연결하도록 요구' 또는 'Allow connections only from computers running Remote Desktop with Network Level Authentication' 이라는 설정 항목이 별도로 존재하는 것을 볼 수 있다.

 윈도우에서 추가되는 거의 모든 패치나 설정들이 그러하지만, 이 설정 또한 윈도우 os의 보안 때문에 존재한다.

 

2. 네트워크 수준 인증(Network Leven Authentication)

이 기능은 RDP 연결 전 그러니까 기술적으로 사용자 세션 생성 전에 사용자의 인증 과정을 먼저 수행하도록 한다. 다음과 같은 순서로 RDP 로그온 과정을 설명할 수 있다.

단계	NLA 비활성화	NLA 활성화
1. 연결 요청	RDP 포트 연결	RDP 포트 연결
2. 세션 생성	GUI 세션 생성	-
3. 사용자 인증	GUI에서 계정 비밀번호 입력 후 인증	클라이언트에서 인증
4. 인증 실패	실패했지만 세션은 생성된 상태	세션 생성되지 않음
5. 인증 성공	세션 시작	세션 생성 + 로그인

 

즉 무슨말이냐 하면

NLA 기능을 활성화하지 않으면 이런 상황이 발생할 수 있다는 것이다.

로그온에는 실패했지만 GUI 세션이 생성되었기 때문에 여전히 이 세션에 접속할 수 있고, 추가적인 공격 벡터가 발생한다.

 

3. 발생할 수 있는 취약점

가장 대표적인 취약점으로 Stickey keys Backdoor를 들 수 있다.

이는 윈도우의 고정키(shift 5번으로 삑삑소리가 나면서 활성화되는) 기능 때문인데, 

(예전에 테스트해본 결과 최근 윈도우 10과 11에서는 보안패치가 적용되긴했으나 조건이 충족되면 동작을 하긴 한다.)

이렇게 로그인을 하지 않았음에도 불구하고 시스템 권한을 가진 셸이 뚝하고 떨어지는 것을 볼 수 있다. 즉 공격자는 손쉽게 system 권한을 손에 넣을 수 있을 뿐만 아니라 Persistance 도 확보할 수 있게 되는 것이다.

 

4. 취약점 발생 경로

두 가지 방법이 있다. 먼저 레지스트리다.

1. 레지스트리

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

경로에서 sethc.exe 키를 추가하고 Debugger 라는 string value를 생성한다음 cmd.exe를 입력한다

 

stickey keys 기능을 활성화한다.

 

2. 파일 이름 변경

두 번째 방법은 %systemroot% 경로에 있는 'sethc.exe' 파일의 이름을 'cmd.exe' 로 변경하는 것이다.

필자가 헷갈렸다. 두 번째 방법은 %systemroot% 경로에 있는 'cmd.exe' 파일의 이름을 'sethc.exe' 로 변경하는 것이다.

 

5. 취약점 탐지 및 방지

 다행히도 최신 패치 버전의 윈도우 10, 11 서버 2016, 2019 등의 운영체제는 디펜더에서 이 백도어를 탐지해 사전에 차단해버린다. 다만 서버 2012와같은 취약한 운영체제에서는 여전히 잘 동작하는 아주 무서운 백도어이기도하다.

 따라서 항상 운영체제 최신 업데이트를 유지하고, 디펜더를 켜거나 또는 다른 백신프로그램을 활성화 하는 것이 가장 좋은 방법이라 할 수 있다.

 또 취약한 운영체제를 분석해야할 경우 위에서 언급한 레지스트리 경로나 파일 경로를 찾아보는 것이 주요한 방법이 되겠다.

 

6. 왜 CMD가 실행이 될까?

 레지스트리 Image File Execution Options 하위 키에 설정할 수 있는 Debugger 값은 해당 프로그램이 실행될 때 대신 실행할 디버거 프로그램을 지정하는 기능이다. 따라서 cmd.exe가 실행된다.

 

7. 왜 SYSTEM 권한이 떨어질까?

시프트 키 다섯 번을 누름으로써 활성화 되는 이 기능은 로그인 전 UI에서 처리하는데, 이 때 로그온을 담당하는 프로세스는 winlogon.exe 또는 logonui.exe 이다. 그런데 이 두 프로세스는 system 권한을 가지고 있다. 또 UI에서 실행되는 시스템 유틸리티는 윈도우 시스템 서비스로 간주된다. 즉 결과적으로 SETHC.EXE 가 저 두 프로세스의 하위 프로세스로 생성이 되고 따라서 cmd가 SYSTEM 권한을 가지게 되는 것이다.

 이러한 윈도우 시스템 서비스를 이용해 SYSTEM권한을 탈취하는 여러 가지 트릭이 있을 수 있다!

 

8. 여담

윈도우 서버 설치 후에 RDP로 접속하려고 하니

원격 컴퓨터에서 NTLM 인증이 차단되었기 때문일 수 있습니다. CredSSP 암호화 Oracle 수정 때문일 수도 있습니다. 라는 에러를 마주했다.

그래서 NLA 기능을 해제 했더니 RDP 연결은 되지만 뭔가 꺼림찍한 기분이 든다. 그래서 이 글을 작성해봤다. 여러분들도 이 방법을 쓰기보다는 다른 방법을 찾아보는게 좋을 것이다.(임시 방편이 될 수는 있지만..)  

 

9. 해당 오류가 자세히 정리된 글

다른 해결 방법을 찾으려면 이 글로 가보세요

https://foxydog.tistory.com/201

원격 데스크톱 연결 : 인증 오류 (NTLM 인증 차단, CredSSP 암호화 Oracle 수정)