2019.03.12

How To : 스마트카드 해킹으로 특수 권한을 획득하는 방법…RSA 시연

Roger A. Grimes | CSO
이메일 주소를 바꿔서 가장 높은 특수 권한의 인증 정보를 훔칠 수 있다.
 
ⓒ Getty Images Bank 

IT 보안에서 꾸준히 권장되는 모범 사례 가운데 하나는 관리자에게 다중 요소 인증(Multi-Factor Authentication, MFA)을 사용하도록 의무화하라는 것이다. 많은 기업 환경에서 이는 스마트카드 사용을 의미한다. 그러나 스마트카드를 사용하는 기업 대부분은 스마트카드 사용으로 인해(액티브 디렉토리 환경에서) 특수 권한 승격이 매우 쉬워진다는 사실을 알지 못한다.

이번 기사에서 설명할 해킹 방법은 새로운 수법이 아니다. 필자는 15년 전에 누군가에게서 이 해킹 방법을 배웠다. 누구였는지는 기억이 나지 않지만 그 사람도 직접 고안한 방법은 아니다. 그런데 지금도 이 해킹 방법을 시연하면 스마트카드 관리자를 포함한 모두가 놀란다. 이 스마트카드 해킹 데모는 2019년 3월 8일 RSA 2019 "12가지 해킹 방법 MFA 프레젠테이션"의 일부이며 본지에서는 처음 공개한다.


다중 요소 인증의 기본 사항

모든 MFA 솔루션은 특정 "대상(subject)"에 연계된다. 대상은 특정 ID의 식별자다. ID는 특정 네임스페이스(예를 들어 DNS, 액티브 디렉토리, LDAP 디렉토리 또는 인증 데이터베이스) 내에서 고유하다는 조건만 충족하면 임의의 레이블, 이름, 이메일 주소, LDAP 주소, DNS 주소, IP 주소 등 거의 무엇이든 될 수 있다. 

인증 디바이스의 여러 인스턴스가 동일한 대상 레이블을 가질 수 있지만 대상 이름은 네임스페이스에서 고유해야 한다. 대부분의 경우 인증 디바이스는 해당 디바이스가 나타내는 대상 레이블에 암호화로 연계된다.

예를 들어 디지털 인증서가 생성되면 여기에 포함되는 많은 필드는 암호화되어 그 디지털 인증서를 만드는 비공개 및 공개 개체로 한정되도록 "보호"된다(즉, 검증 가능함을 의미). 대상 이름을 변경하면 그 즉시 디지털 인증서가 무효화된다. 사용자는 인증 디바이스를 제공함으로써 자신이 누구인지 주장하므로 이런 방식은 타당하다. 그런 다음 사용자는 비밀번호, PIN 또는 생체 정보를 제공함으로써 인증 디바이스에 의해 입증된 대상을 자신이 소유하고 있음을 증명한다.

제출된 대상/ID의 소유를 증명하면 인증이 이뤄진다. 인증된 ID는 일반적으로 대상별 액세스 제어 쿠키 또는 토큰과 연결된다. 이 토큰은 해당 ID가 보호되는 정보에 액세스를 시도할 때 시스템(운영체제)의 액세스 제어 확인 구성요소에 제시된다. 쿠키 또는 토큰은 할당된 권한, 특권 및 기타 인증 속성(예를 들어 그룹 멤버십)과 연결된다.

해커가 대상의 액세스 제어 쿠키 또는 토큰을 장악하는 경우, 일반적으로 그 해커는 실제 사용자/대상처럼 취급된다. 시스템(운영체제)에는 액세스 제어 쿠키 또는 토큰을 제시하는 대상이 실제 그 사용자인지 여부를 알 방법이 없는 경우가 많다. 시스템은 제출되는 모든 액세스 제어 쿠키 또는 토큰이 유효하며 이전에 검증된 사용자에 의해 적절히 사용되고 있다고 전제한다.


대상 하이재킹 공격의 원리

이 형태의 해킹을 이해하려면 대상 레이블이 전체 인증 프로세스에서 갖는 의미를 이해하는 것이 중요하다. 전체적인 해킹은 이렇게 요약할 수 있다. 공격자가 기업의 인증 방법에 연결된 대상 레이블을 훔칠 수 있다면, 해당 기업이 설령 매우 안전하고 신뢰할 수 있는 MFA를 사용한다 해도 공격자는 ID를 훔칠 수 있게 된다.

데모를 위해 액티브 디렉토리와 AD 통합 스마트카드를 사용한 예를 살펴보자. 수많은 액티브 디렉토리 사용자와 관리자는 이 구성을 사용해서 로그온을 보호한다. 이 해킹 데모에서 공격자는 권한이 낮은 유효한 사용자다(이름은 HelpDesk). ID 절도 공격의 대상은 액티브 디렉토리의 모든 승격된 권한 그룹(스키마 관리자, 엔터프라이즈 관리자, 도메인 관리자)에 속한 높은 특권을 가진 사용자(이름은 SuperAdmin)다.

헬프데스크가 일반 사용자 수준 이상으로 보유한 유일한 승격된 특수 권한은 사용자의 액티브 디렉토리 UPN(User Principal Name)을 변경할 수 있는 권한이다. 이와 같은 종류의 권한은 저수준 관리자에게 흔히 부여된다. 사용자의 UPN은 그럴 필요가 없음에도 불구하고 많은 경우 사용자의 이메일 주소와 동일하다. UPN의 유일한 요구 사항은 동일한 액티브 디렉토리 포리스트 내에서 고유해야 한다는 것이다.

이번 해킹 방법을 요약하면 다음과 같다.
1. 낮은 권한의 헬프데스크 관리자가 슈퍼어드민(SuperAdmin)과 UPN을 바꿈
2. 헬프데스크 관리자가 자신의 헬프데스크 스마트카드와 PIN을 사용해 로그인
3. 헬프데스크 관리자가 슈퍼어드민이 됨(모든 그룹 멤버십 포함)
4. 헬프데스크가 악의적인 동작을 수행
5. 시스템은 모든 작업을 슈퍼어드민으로 추적함
6. 헬프데스크는 작업을 마치고 로그아웃하고 UPN을 원래대로 다시 변경함. 무슨 일이 일어났는지 아무도 모름


각자의 액티브 디렉토리 환경에서 사용자 UPN을 바꿀 권한을 가진 사람이 몇 명인지 자문해 보자. 이벤트 로깅 시스템이 UPN 변경을 탐지하고 경고하는가, 아마 대부분의 환경에서는 그렇지 않을 것이다.


단계별 스마트카드 해킹 데모

필자가 RSA 컨퍼런스에서 발표한 데모를 설명하면 다음과 같다.

1. 슈퍼어드민의 UPN(액티브 디렉토리에서 "사용자 로그온 이름"으로 표시됨)을 확인한다.
 
ⓒ ROGER GRIMES

2. 슈퍼어드민이 승격된 권한 그룹에 속하는지 확인한다.
ⓒ ROGER GRIMES

3. 슈퍼어드민의 UPN이 슈퍼어드민의 스마트카드에 연결되어 있는지 확인한다(슈퍼어드민의 스마트카드와 연계된 고유한 디지털 인증서 지문 포함).
ⓒ ROGER GRIMES

4. 슈퍼어드민의 스마트카드와 PIN을 사용해 슈퍼어드민으로 로그온한다.
ⓒ ROGER GRIMES

5. 슈퍼어드민이 슈퍼어드민의 스마트카드와 PIN을 사용해 성공적으로 로그온했는지 확인한다.
ⓒ ROGER GRIMES

6. 슈퍼어드민에게 승격된 그룹 멤버십이 있는지 확인한다.
ⓒ ROGER GRIMES

7. 권한이 낮은 헬프데스크 사용자가 자신의 스마트카드와 PIN을 사용해 로그온한다(해킹이 이뤄지기 전에 현재 상태를 보여주기 위해서임).
ⓒ ROGER GRIMES

8. 헬프데스크의 스마트카드 정보는 helpdesk@victim.com UPN과 헬프데스크의 고유한 디지털 인증서 지문을 보여준다.
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES

9. 낮은 권한의 헬프데스크 사용자가 액티브 디렉토리 사용자 및 컴퓨터를 사용해 자신의 UPN을 슈퍼어드민 사용자와 바꾼다. 액티브 디렉토리는 두 계정이 동시에 동일한 UPN을 공유하는 것을 허용하지 않으므로, 이를 위해 헬프데스크 사용자는 먼저 다른 값을 사용해 자신의 UPN으로 변경해야 한다.

10. 헬프데스크 사용자가 슈퍼어드민의 UPN을 helpdesk@victim.com으로 업데이트해 자체 스마트카드에 저장된 UPN과 똑같이 만든다.
ⓒ ROGER GRIMES

11. 헬프데스크 사용자는 로그아웃하고 액티브 디렉토리 복제가 실행되는 몇 분 동안 기다린 다음 다시 로그인한다.
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES

12. 헬프데스크 사용자는 자신과 연결된 헬프데스크 스마트카드와 PIN을 사용해 로그온했지만 이제 슈퍼어드민의 UPN이 helpdesk@victim.com이므로 액티브 디렉토리는 이 헬프데스크 사용자를 슈퍼어드민 사용자와 연결한다.
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES

이 시점에서 헬프데스크 사용자는 슈퍼어드민이 현재 할 수 있는 모든 작업을 할 수 있고, 마이크로소프트 윈도우와 액티브 디렉토리는 모든 윈도우 이벤트를 헬프데스크가 아닌 슈퍼어드민에서 발생한 것으로 추적한다. 헬프데스크 사용자는 보안 인증 정보를 언제든 승격할 수 있는지 확인하는 등 다른 무단 작업을 수행한 후 UPN을 다시 바꿀 수 있다. UPN 업데이트가 로깅되고 누군가가 이 로그에 내포된 중대한 의미를 인지하지 않는 한 실제로 무슨 일이 일어났는지 알기가 어렵다.

일부 로그온 이벤트는 이벤트 ID 4768과 같이 도메인 컨트롤러에 등록되는데, 여기에는 제공된 스마트카드의 지문이 포함될 수 있다. 이 부분을 검토하면 헬프데스크 사용자의 스마트카드가 슈퍼어드민 계정과 연결되었다는 것을 알 수 있지만 이를 위해서는 포렌식 조사관이 이와 같은 해킹 시나리오를 인지하고 확인해야 한다. 실제로 어떤 일이 일어났는 지를 발견하기란 쉽지 않다.

흥미로운 해킹이다.

다른 사용자의 UPN을 변경할 수 있고 이전에 검증된 사용자 계정이 필요한 공격이라면 애초에 공격 기준이 상당히 까다롭다고 주장할 수 있는데, 필자도 동의한다. 이 해킹은 대상 하이재킹 공격으로 일어날 수 있는 일을 보여주기 위한 하나의 예다. 다른 솔루션을 사용하는 비슷한 공격에서는 사전 요건이 그다지 까다롭지 않을 수도 있다.

이 액티브 디렉토리 해킹에서도 유효하고 신뢰된 다른 스마트카드 ID를 사용할 수 있다(해당 ID가 피해자의 액티브 디렉토리에 존재하지 않는 경우에도 가능). frog@victim.com(액티브 디렉토리의 사용자로 존재하지 않음)의 대상으로 새 스마트카드를 만들어 슈퍼어드민의 UPN을 frog@victim.com으로 변경하고 유효한 PIN을 사용해 frog@victim.com으로 로그인하면 액티브 디렉토리는 frog@victim.com이 슈퍼어드민 계정의 UPN을 제외한 다른 어디에도 존재하지 않는다는 사실을 문제삼지 않는다.


기억해야 할 스마트카드 해킹 교훈

이 점만은 명확히 짚고 넘어가자. 이것은 마이크로소프트 또는 액티브 디렉토리 버그가 아니다. 스마트카드가 원래 그렇게 작동하도록 만들어진 것이고, 앞으로 수정될 일도 없다. 스마트카드의 대상이 하이재킹되도록 허용하면 언젠가는 이런 종류의 해악이 발생하게 된다. 대상 하이재킹이 가능한 경우 다른 MFA 솔루션에도 비슷한 공격이 감행될 가능성이 높다.

이번 시연의 교훈은 인증에 사용되는 모든 속성을 비밀번호와 똑같이 취급해야 한다는 것이다. 우리는 비밀번호 노출과 도난을 방지하기 위해 온갖 종류의 로깅과 보호 수단을 마련해두고 있지만 다른 인증 속성에 대한 보호 수단도 확보해야만 한다. editor@itworld.co.kr 
 


2019.03.12

How To : 스마트카드 해킹으로 특수 권한을 획득하는 방법…RSA 시연

Roger A. Grimes | CSO
이메일 주소를 바꿔서 가장 높은 특수 권한의 인증 정보를 훔칠 수 있다.
 
ⓒ Getty Images Bank 

IT 보안에서 꾸준히 권장되는 모범 사례 가운데 하나는 관리자에게 다중 요소 인증(Multi-Factor Authentication, MFA)을 사용하도록 의무화하라는 것이다. 많은 기업 환경에서 이는 스마트카드 사용을 의미한다. 그러나 스마트카드를 사용하는 기업 대부분은 스마트카드 사용으로 인해(액티브 디렉토리 환경에서) 특수 권한 승격이 매우 쉬워진다는 사실을 알지 못한다.

이번 기사에서 설명할 해킹 방법은 새로운 수법이 아니다. 필자는 15년 전에 누군가에게서 이 해킹 방법을 배웠다. 누구였는지는 기억이 나지 않지만 그 사람도 직접 고안한 방법은 아니다. 그런데 지금도 이 해킹 방법을 시연하면 스마트카드 관리자를 포함한 모두가 놀란다. 이 스마트카드 해킹 데모는 2019년 3월 8일 RSA 2019 "12가지 해킹 방법 MFA 프레젠테이션"의 일부이며 본지에서는 처음 공개한다.


다중 요소 인증의 기본 사항

모든 MFA 솔루션은 특정 "대상(subject)"에 연계된다. 대상은 특정 ID의 식별자다. ID는 특정 네임스페이스(예를 들어 DNS, 액티브 디렉토리, LDAP 디렉토리 또는 인증 데이터베이스) 내에서 고유하다는 조건만 충족하면 임의의 레이블, 이름, 이메일 주소, LDAP 주소, DNS 주소, IP 주소 등 거의 무엇이든 될 수 있다. 

인증 디바이스의 여러 인스턴스가 동일한 대상 레이블을 가질 수 있지만 대상 이름은 네임스페이스에서 고유해야 한다. 대부분의 경우 인증 디바이스는 해당 디바이스가 나타내는 대상 레이블에 암호화로 연계된다.

예를 들어 디지털 인증서가 생성되면 여기에 포함되는 많은 필드는 암호화되어 그 디지털 인증서를 만드는 비공개 및 공개 개체로 한정되도록 "보호"된다(즉, 검증 가능함을 의미). 대상 이름을 변경하면 그 즉시 디지털 인증서가 무효화된다. 사용자는 인증 디바이스를 제공함으로써 자신이 누구인지 주장하므로 이런 방식은 타당하다. 그런 다음 사용자는 비밀번호, PIN 또는 생체 정보를 제공함으로써 인증 디바이스에 의해 입증된 대상을 자신이 소유하고 있음을 증명한다.

제출된 대상/ID의 소유를 증명하면 인증이 이뤄진다. 인증된 ID는 일반적으로 대상별 액세스 제어 쿠키 또는 토큰과 연결된다. 이 토큰은 해당 ID가 보호되는 정보에 액세스를 시도할 때 시스템(운영체제)의 액세스 제어 확인 구성요소에 제시된다. 쿠키 또는 토큰은 할당된 권한, 특권 및 기타 인증 속성(예를 들어 그룹 멤버십)과 연결된다.

해커가 대상의 액세스 제어 쿠키 또는 토큰을 장악하는 경우, 일반적으로 그 해커는 실제 사용자/대상처럼 취급된다. 시스템(운영체제)에는 액세스 제어 쿠키 또는 토큰을 제시하는 대상이 실제 그 사용자인지 여부를 알 방법이 없는 경우가 많다. 시스템은 제출되는 모든 액세스 제어 쿠키 또는 토큰이 유효하며 이전에 검증된 사용자에 의해 적절히 사용되고 있다고 전제한다.


대상 하이재킹 공격의 원리

이 형태의 해킹을 이해하려면 대상 레이블이 전체 인증 프로세스에서 갖는 의미를 이해하는 것이 중요하다. 전체적인 해킹은 이렇게 요약할 수 있다. 공격자가 기업의 인증 방법에 연결된 대상 레이블을 훔칠 수 있다면, 해당 기업이 설령 매우 안전하고 신뢰할 수 있는 MFA를 사용한다 해도 공격자는 ID를 훔칠 수 있게 된다.

데모를 위해 액티브 디렉토리와 AD 통합 스마트카드를 사용한 예를 살펴보자. 수많은 액티브 디렉토리 사용자와 관리자는 이 구성을 사용해서 로그온을 보호한다. 이 해킹 데모에서 공격자는 권한이 낮은 유효한 사용자다(이름은 HelpDesk). ID 절도 공격의 대상은 액티브 디렉토리의 모든 승격된 권한 그룹(스키마 관리자, 엔터프라이즈 관리자, 도메인 관리자)에 속한 높은 특권을 가진 사용자(이름은 SuperAdmin)다.

헬프데스크가 일반 사용자 수준 이상으로 보유한 유일한 승격된 특수 권한은 사용자의 액티브 디렉토리 UPN(User Principal Name)을 변경할 수 있는 권한이다. 이와 같은 종류의 권한은 저수준 관리자에게 흔히 부여된다. 사용자의 UPN은 그럴 필요가 없음에도 불구하고 많은 경우 사용자의 이메일 주소와 동일하다. UPN의 유일한 요구 사항은 동일한 액티브 디렉토리 포리스트 내에서 고유해야 한다는 것이다.

이번 해킹 방법을 요약하면 다음과 같다.
1. 낮은 권한의 헬프데스크 관리자가 슈퍼어드민(SuperAdmin)과 UPN을 바꿈
2. 헬프데스크 관리자가 자신의 헬프데스크 스마트카드와 PIN을 사용해 로그인
3. 헬프데스크 관리자가 슈퍼어드민이 됨(모든 그룹 멤버십 포함)
4. 헬프데스크가 악의적인 동작을 수행
5. 시스템은 모든 작업을 슈퍼어드민으로 추적함
6. 헬프데스크는 작업을 마치고 로그아웃하고 UPN을 원래대로 다시 변경함. 무슨 일이 일어났는지 아무도 모름


각자의 액티브 디렉토리 환경에서 사용자 UPN을 바꿀 권한을 가진 사람이 몇 명인지 자문해 보자. 이벤트 로깅 시스템이 UPN 변경을 탐지하고 경고하는가, 아마 대부분의 환경에서는 그렇지 않을 것이다.


단계별 스마트카드 해킹 데모

필자가 RSA 컨퍼런스에서 발표한 데모를 설명하면 다음과 같다.

1. 슈퍼어드민의 UPN(액티브 디렉토리에서 "사용자 로그온 이름"으로 표시됨)을 확인한다.
 
ⓒ ROGER GRIMES

2. 슈퍼어드민이 승격된 권한 그룹에 속하는지 확인한다.
ⓒ ROGER GRIMES

3. 슈퍼어드민의 UPN이 슈퍼어드민의 스마트카드에 연결되어 있는지 확인한다(슈퍼어드민의 스마트카드와 연계된 고유한 디지털 인증서 지문 포함).
ⓒ ROGER GRIMES

4. 슈퍼어드민의 스마트카드와 PIN을 사용해 슈퍼어드민으로 로그온한다.
ⓒ ROGER GRIMES

5. 슈퍼어드민이 슈퍼어드민의 스마트카드와 PIN을 사용해 성공적으로 로그온했는지 확인한다.
ⓒ ROGER GRIMES

6. 슈퍼어드민에게 승격된 그룹 멤버십이 있는지 확인한다.
ⓒ ROGER GRIMES

7. 권한이 낮은 헬프데스크 사용자가 자신의 스마트카드와 PIN을 사용해 로그온한다(해킹이 이뤄지기 전에 현재 상태를 보여주기 위해서임).
ⓒ ROGER GRIMES

8. 헬프데스크의 스마트카드 정보는 helpdesk@victim.com UPN과 헬프데스크의 고유한 디지털 인증서 지문을 보여준다.
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES

9. 낮은 권한의 헬프데스크 사용자가 액티브 디렉토리 사용자 및 컴퓨터를 사용해 자신의 UPN을 슈퍼어드민 사용자와 바꾼다. 액티브 디렉토리는 두 계정이 동시에 동일한 UPN을 공유하는 것을 허용하지 않으므로, 이를 위해 헬프데스크 사용자는 먼저 다른 값을 사용해 자신의 UPN으로 변경해야 한다.

10. 헬프데스크 사용자가 슈퍼어드민의 UPN을 helpdesk@victim.com으로 업데이트해 자체 스마트카드에 저장된 UPN과 똑같이 만든다.
ⓒ ROGER GRIMES

11. 헬프데스크 사용자는 로그아웃하고 액티브 디렉토리 복제가 실행되는 몇 분 동안 기다린 다음 다시 로그인한다.
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES

12. 헬프데스크 사용자는 자신과 연결된 헬프데스크 스마트카드와 PIN을 사용해 로그온했지만 이제 슈퍼어드민의 UPN이 helpdesk@victim.com이므로 액티브 디렉토리는 이 헬프데스크 사용자를 슈퍼어드민 사용자와 연결한다.
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES
ⓒ ROGER GRIMES

이 시점에서 헬프데스크 사용자는 슈퍼어드민이 현재 할 수 있는 모든 작업을 할 수 있고, 마이크로소프트 윈도우와 액티브 디렉토리는 모든 윈도우 이벤트를 헬프데스크가 아닌 슈퍼어드민에서 발생한 것으로 추적한다. 헬프데스크 사용자는 보안 인증 정보를 언제든 승격할 수 있는지 확인하는 등 다른 무단 작업을 수행한 후 UPN을 다시 바꿀 수 있다. UPN 업데이트가 로깅되고 누군가가 이 로그에 내포된 중대한 의미를 인지하지 않는 한 실제로 무슨 일이 일어났는지 알기가 어렵다.

일부 로그온 이벤트는 이벤트 ID 4768과 같이 도메인 컨트롤러에 등록되는데, 여기에는 제공된 스마트카드의 지문이 포함될 수 있다. 이 부분을 검토하면 헬프데스크 사용자의 스마트카드가 슈퍼어드민 계정과 연결되었다는 것을 알 수 있지만 이를 위해서는 포렌식 조사관이 이와 같은 해킹 시나리오를 인지하고 확인해야 한다. 실제로 어떤 일이 일어났는 지를 발견하기란 쉽지 않다.

흥미로운 해킹이다.

다른 사용자의 UPN을 변경할 수 있고 이전에 검증된 사용자 계정이 필요한 공격이라면 애초에 공격 기준이 상당히 까다롭다고 주장할 수 있는데, 필자도 동의한다. 이 해킹은 대상 하이재킹 공격으로 일어날 수 있는 일을 보여주기 위한 하나의 예다. 다른 솔루션을 사용하는 비슷한 공격에서는 사전 요건이 그다지 까다롭지 않을 수도 있다.

이 액티브 디렉토리 해킹에서도 유효하고 신뢰된 다른 스마트카드 ID를 사용할 수 있다(해당 ID가 피해자의 액티브 디렉토리에 존재하지 않는 경우에도 가능). frog@victim.com(액티브 디렉토리의 사용자로 존재하지 않음)의 대상으로 새 스마트카드를 만들어 슈퍼어드민의 UPN을 frog@victim.com으로 변경하고 유효한 PIN을 사용해 frog@victim.com으로 로그인하면 액티브 디렉토리는 frog@victim.com이 슈퍼어드민 계정의 UPN을 제외한 다른 어디에도 존재하지 않는다는 사실을 문제삼지 않는다.


기억해야 할 스마트카드 해킹 교훈

이 점만은 명확히 짚고 넘어가자. 이것은 마이크로소프트 또는 액티브 디렉토리 버그가 아니다. 스마트카드가 원래 그렇게 작동하도록 만들어진 것이고, 앞으로 수정될 일도 없다. 스마트카드의 대상이 하이재킹되도록 허용하면 언젠가는 이런 종류의 해악이 발생하게 된다. 대상 하이재킹이 가능한 경우 다른 MFA 솔루션에도 비슷한 공격이 감행될 가능성이 높다.

이번 시연의 교훈은 인증에 사용되는 모든 속성을 비밀번호와 똑같이 취급해야 한다는 것이다. 우리는 비밀번호 노출과 도난을 방지하기 위해 온갖 종류의 로깅과 보호 수단을 마련해두고 있지만 다른 인증 속성에 대한 보호 수단도 확보해야만 한다. editor@itworld.co.kr 
 


X