By rls1004 | December 7, 2016
20년 된 MS 로그인 취약점 이슈
MS 로그인 취약점 이슈
얼마 전, MS가 20년 된 로그인 취약점을 패치하지 않기로 했다는 기사를 봤습니다.
20년이나 존재할 수 있는 취약점이 있다니, 어떤 취약점 일까요??
개념 알고 가기
SMB?
# 출처 : Just what is SMB?
SMB는 Server Message Block의 약자로, Microsoft와 Intel에서 만든 프로토콜입니다.
윈도우 시스템이 다른 시스템과 파일, 디렉토리, 주변 장치 등의 자원을 공유할 수 있도록 하기 위해 개발되었습니다.
클라이언트는 서버에게 파일 서비스를 요구하고,
서버는 그에 대한 응답으로 자신의 파일 시스템이나 프린터와 같은 여러가지 로컬 자원을 클라이언트가 사용할 수 있도록 공개합니다.
주로 마이크로소프트 윈도우를 실행하는 컴퓨터에서 사용됩니다.
SMBA?
SMB 프로토콜을 지원하는 소프트웨어 중 하나입니다.
윈도우와 리눅스 컴퓨터 간에 데이터를 교환해야할 일이 생겼을 때,
리눅스 컴퓨터에 삼바 서버를 설치하면 윈도우의 파일 탐색기로 우분투 컴퓨터에 접근하여 파일을 읽고 쓸 수 있습니다.
NTLM?
NTLM은 NT Lan Manager(또는 NT LanMan)의 약자로,
Windows Msv1_0.dll에 포함된 인증 프로토콜이며 Windows NT 제품군의 모든 구성원이 사용하고,
윈도우 네트워크의 인증에 가장 많이 사용되는 인증 절차입니다.
NTLM은 Challenge-Response 매커니즘을 사용하는데 인증 절차는 다음과 같습니다
로컬 계정
클라이언트가 서버에 로그온 요청을 보낸다.
서버는 이에 대한 Challenge(토큰)를 생성해 클라이언트로 보낸다.
클라이언트는 이 Challenge를 이용하여 사용자 암호를 해싱한 결과인 Response를 서버로 보낸다.
서버는 SAM(Security Account Manager)을 검색해 사용자의 응답을 검증한다.
인증이 완료되면 성공적으로 로그인된다.
도메인 계정
클라이언트가 서버에 파일을 요청한다.
서버는 이에 대한 Challenge를 생성해 클라이언트로 보낸다.
클라이언트는 이 Challenge를 이용하여 사용자 암호를 해싱한 결과인 Response를 서버로 보낸다.
서버는 username, Challenge, Response를 도메인 컨트롤러에게 보낸다.
도메인 컨트롤러는 사용자를 인증하기 위해 Challenge와 Response를 비교하는데,
그 둘이 매치되는 값이라면 서버에게 인증이 확인됐음을 알린다.인증이 확인되면 서버는 클라이언트에게 파일에 대한 접근 권한을 부여한다.
이슈
1997년, Single Sign-On (SSO) 의 등장
수많은 서비스들이 등장함에 따라 각각의 서비스에 대한 자신의 인증 정보를 기억하고,
입력해야하는 불편함과 여러가지 이유들로 인해 Single Sign-On(이하 SSO) 이라는 개념이 등장했습니다.
SSO는 하나의 계정으로, 한 번의 인증 과정으로 여러 응용 프로그램을 이용 가능하게 하는 기술입니다.
구글의 SSO를 예로 들어보면 Gamil에 로그인 한 다음에는
YouTube 등 다른 구글 서비스를 이용할 때 추가적인 인증 과정이 필요하지 않습니다.
# 출처 : Microsoft Office 365 Single Sign-on
Office 365 등 마이크로소프트 또한 SSO 방식을 이용하고 있는데요,
사용자가 자원에 접근하면 윈도우즈는 NTLM 인증 방식을 사용하여 호스트에게 도메인 네임, 유저 네임, 패스워드 해쉬를 전송합니다.
오직, 인증이 실패했을 경우만 로그인 프롬프트가 뜨게 됩니다.
서비스를 전환할 때마다 로그인을 해야하는 상황을 생각하면 SSO의 등장이 참 고맙습니다.
SSO의 등장으로 개인의 불편함은 해소되고, 기업은 회원에 대한 통합 관리가 가능해졌습니다.
1997년, MS 로그인 취약점 최초 발견
SSO는 편리한 기능이지만 자동으로 사용자에 대한 인증을 해결하다보니 시간이 지남에 따라 몇몇 문제가 발생합니다.
그 중엔 고쳐진 것도 있고 고쳐지지 않은 문제도 있는데요,
인터넷을 통해 SMB 서버로 사용자의 자격증명을 전송하는 문제는 고쳐지지 않은 문제 중 하나입니다.
이 문제는 지금으로부터 약 20년 전인 1997년, Aaron Spangler라는 사람에 의해 발견된 취약점입니다.
윈도우 95는 자동으로 SMB 서버에 사용자의 인증을 시도하고 있고, 그로 인해 유저 네임과 암호화된 패스워드를 얻어낼 수 있습니다.
file://server/share/image.gif
웹 사이트에서 위와 같은 경로에 위치한 이미지를 포함하게 되면,
이미지를 다운받는 과정에서 윈도우는 “server”의 IP에 해당하는 SMB 서버에 사용자 인증을 요청하게 됩니다.
이미지를 요청하기 위해서 클라이언트는 SMB 서버에 자격 증명을 해야하는데요,
윈도우는 사용자에게 확인을 거치지 않고 자동으로 이 작업을 수행합니다.
SMB 서버는 유저 네임과 암호화된 패스워드를 기록하고,
패스워드를 암호화하는데 쓰이는 Challenge 시드 값을 고정으로 설정하도록 코드가 수정된 악의적인 SMB 서버입니다.
이를 통해 사용자는 아무것도 모른채 SMB 서버에 계정정보를 유출하게 됩니다.
이미지 뿐만 아니라 이메일 등을 보내어 트리거할 수도 있습니다.
암호화된 패스워드라 괜찮지 않냐구요?
패스워드는 NTLM 알고리즘으로 암호화되어 있는데, 크랙이 가능한 것으로 알려져있습니다.
NTLM 알고리즘
암호화할 문자를 유니코드로 변환한 후 MD4 알고리즘을 적용하여 128 비트 해시값을 생성한다.
2015년, 다시 주목받는 취약점
윈도우 8이 등장하면서 이 취약점은 다시 주목받게 되었습니다.
윈도우 7에서 윈도우 8로 넘어가면서 로컬 계정 대신 MS 계정을 사용하게 되었습니다.
MS 계정 없이는 애플리케이션 스토어, OneDrive 등에 접근할 수 없고,
MS 계정으로 Outlook, Office, Skype 등에 로그인하게 되었으며, MS 계정을 이용하면 쉽고 편하게
이메일, 파일, 설정 등을 동기화할 수 있는 편리한 환경이 되었습니다.
즉, 로그인 취약점이 로컬 계정에 대한 문제에서 MS 계정에 대한 문제로 범위가 커진 것 입니다.
지금은 공격자가 MS 계정에 대한 모든 권한을 수행할 수 있게 되었습니다.
과거로부터 존재했던 이 취약점을 이용한 새로운 익스플로잇들도 나타났고, 2015년 BlackHat 컨퍼런스에서 다시 언급되기도 했습니다.
FileCry - The New Age of XXE
https://www.youtube.com/watch?v=ouBwRZJHmmo
SMB : SHARING MORE THAN JUST YOUR FILES
https://www.youtube.com/watch?v=O5TfXKjbwyk
2016년, 패치하지 않는다
그리고 이 취약점은 올해 다시 한 번 주목받습니다.
# 기사원문 : ZDNet.com
마이크로소프트에서 이 취약점을 패치하지 않는다고 한 것인데요.
마이크로소프트의 대변인에 따르면,
이 문제를 패치하지 않기로 했고 필요하다면 사용자들을 보호하기 위한 지침을 배포하며 추가적인 조치를 취한다고 합니다.
왜 패치하지 않는지에 대한 이유는 정확히 알려진 바가 없는 것 같습니다.
대응책?
계정 정보를 보호할 수 있는 대응 방안이 없을까요?
VPN 제공사인 Perfect Privacy에서 몇가지 방안을 제시했습니다.
IE(Internet Explorer), Edge 등 인터넷을 통해 네트워크 공유에 접근하는 MS 소프트웨어를 사용하지 않는다.
MS 계정으로 윈도우에 로그인하지 않는다.
라우터/방화벽에서 445(SMB)와 137-139로 나가는 포트를 차단한다.
윈도우 방화벽을 사용하여, 로컬 주소 영역이 아닌 곳으로 나가는 445(SMB)와 137-139 포트를 차단한다.
크롬과 파이어폭스는 이 취약점에 영향을 받지 않습니다.
또, 위 사이트에서 자신의 컴퓨터가 이 문제에 취약한지 여부를 알 수 있습니다.
Perfect Privacy에서 자체적으로 만든 테스트 페이지 인데요,
테스트 버튼을 누르면 MS 유저 네임과 패스워드 해쉬 값이 평문으로 전송되기 때문에 주의하셔야 합니다.
테스트는 IE나 Edge로 진행할 수 있으며 결과로 로그인 패스워드나 패스워드 해쉬 값이 뜰 경우는 조치가 필요합니다.
패치를 하지 않는 이유에 대해서는 의문이지만 간단한 방화벽 설정을 통해 방지할 수 있으므로 미리미리 적용하도록 합시다~