Microsoft Edge는 사용하지 않을 때도 모든 비밀번호를 메모리에 평문으로 저장함
(twitter.com/L1v1ng0ffTh3L4N)- Microsoft Edge는 저장된 비밀번호를 시작 시점에 모두 복호화하고, 해당 자격 증명을 프로세스 메모리에 평문으로 상주시킴
- 사용자가 해당 자격 증명을 쓰는 사이트를 방문하지 않아도 이 동작이 발생함
- Edge의 Password Manager UI는 같은 비밀번호를 표시하기 전에 재인증을 요구하지만, 브라우저 프로세스는 이미 모든 비밀번호를 평문으로 보유하고 있음
- 테스트한 Chromium 기반 브라우저 중 Edge만 이런 방식으로 동작했으며, Chrome은 저장 비밀번호를 단순히 프로세스 메모리에서 읽어 추출하기 더 어렵게 설계돼 있음
- Chrome은 자격 증명이 필요할 때만 복호화하고, App-Bound Encryption(ABE) 으로 복호화를 인증된 Chrome 프로세스에 묶어 다른 프로세스가 Chrome의 암호화 키를 재사용하지 못하게 함
- 이 제어로 평문 비밀번호는 자동완성이나 사용자가 직접 볼 때만 짧게 나타나며, 광범위한 메모리 스크래핑의 효과가 낮아짐
위험 시나리오와 공개 상태
- 공유 환경에서는 평문 비밀번호를 메모리에 유지하는 위험이 커짐
- 공격자가 터미널 서버에서 관리자 권한을 얻으면 로그인한 모든 사용자 프로세스의 메모리에 접근할 수 있음
- 시연에서는 관리자 권한이 있는 사용자 계정을 장악한 공격자가 Edge가 실행 중인 다른 두 로그인 사용자 또는 연결이 끊긴 사용자의 저장 자격 증명을 볼 수 있었음
- Microsoft에 이 동작을 보고했고, 공식 답변은 해당 동작이 “by design”이라는 것이었음
- 사용자와 조직이 자격 증명 관리 방식을 판단할 수 있도록 책임 있는 공개로 공유하겠다는 방침을 Microsoft에 전달함
- 4월 29일 수요일, Palo Alto Networks Norway의 BigBiteOfTech에서 이 내용을 공개했고, 비밀번호가 메모리에 평문으로 저장되는지 쉽게 확인할 수 있는 단순한 도구를 시연함
- 개념 증명 도구는 GitHub에 공개됐으며, C#과 GitHub 배포 경험이 많지 않아 피드백을 받고 있음: EdgeSavedPasswordsDumper
Hacker News 의견들
- 이건 밀폐 해치 반대편에 이미 들어와 있는 상황에 가까움. 임의 프로세스 메모리를 읽을 수 있다면, 해당 사용자로 가장해서 비밀번호를 그냥 덤프할 수도 있는 위치일 가능성이 큼
공격자가 터미널 서버 관리자 권한을 얻으면 로그인한 모든 사용자 프로세스의 메모리에 접근 가능하고, 관리자 권한이면 모든 Chrome 프로세스에 디버거를 붙여 비밀번호 복호화를 강제할 수도 있음
실제 차이는 콜드 부팅 공격 정도인데, 그마저도 공격을 조금 쉽게 만드는지, 아니면 원래 불가능한 공격을 가능하게 하는지는 불분명함
[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...- 이 논리는 Chromium 위협 모델과 완전히 맞아떨어짐. 공격자가 관리자 권한을 얻은 순간 정의상 게임 오버임
Edge만의 문제일 가능성은 낮아 보이고, Microsoft가 상류 프로젝트보다 브라우저를 덜 안전하게 만들 이유도 없음
Chrome은 물리적으로 로컬인 공격을 위협 모델 밖으로 보는데, 사용자가 내 기기에 나로 로그인했거나 내 운영체제 사용자 권한으로 소프트웨어를 실행할 수 있으면 Chrome이나 어떤 앱도 방어할 방법이 없다고 봄
그런 공격자는 실행 파일과 DLL 수정, PATH 같은 환경 변수 변경, 설정 파일 변경, 사용자 계정 데이터 읽기와 외부 전송까지 가능하므로, Chrome이 제공할 수 있는 실질적 방어 보장은 없다는 입장임
https://chromium.googlesource.com/chromium/src/+/148.0.7778.... - 최근 몇 년 사이에는 일반 사용자 권한만으로도 임의 메모리 읽기가 가능했던 브라우저 취약점들이 있었고, 다만 느리거나 위치 제어가 완전하지 않은 식이었음. 사용 직후 자격 증명을 가능한 빨리 지우는 건 해자 하나를 더 파는 정도라도 꽤 합리적인 예방책으로 봄
- 보안은 흑백이 아님. 로그인 정보를 적은 포스트잇을 모니터에 붙여두는 건 잠기지 않은 서랍에 넣어두는 것보다 분명히 더 위험한 식으로 단계가 있음
- 사용자 입장에서는 비밀번호를 붙여넣으려 할 때마다 먼저 생체 인증으로 로그인해야 하는데, 아무 사용자 프로세스나 메모리에서 비밀번호를 낚아챌 수 있다는 건가?
뭘 놓치고 있는지 모르겠음 - 벌써 Cloudbleed를 잊은 건가?
[0] https://en.wikipedia.org/wiki/Cloudbleed
- 이 논리는 Chromium 위협 모델과 완전히 맞아떨어짐. 공격자가 관리자 권한을 얻은 순간 정의상 게임 오버임
- 참고로 Google은 Chrome이 메모리의 비밀번호를 암호화해 저장하고, 다른 프로세스가 Chrome인 척해서 평문 비밀번호에 접근하지 못하게 권한 상승 서비스를 쓴다고 설명함: https://security.googleblog.com/2024/07/improving-security-o...
- 명확히 말하자면 가능한 공격 경로 중 하나는, 컴퓨터를 잠그지 않고 화장실에 5분 다녀오는 사이 악의적인 해커가 돌아오기 전에 모든 비밀번호를 덤프하는 상황임
이건 고려할 가치가 있다고 봄. 비밀번호 관리자가 10분 뒤에 마스터 비밀번호나 패스키를 다시 요구하는 데는 이유가 있음
Chrome이 암호화된 보안 영역에 의존한다고 생각했기 때문에, 루트 권한이 있어도 비밀번호를 쉽게 추출하는 건 꽤 어렵다고 여겼음
물론 컴퓨터를 방치하면 안 됨. 하지만 피할 수 없는 실수를 치명적으로 악용하기 쉽게 제품을 설계해도 된다는 뜻은 아님 - 이 도구가 같은 머신에서 실행 중인 Edge 인스턴스에 접근하는 건가? 그렇다면 저장된 비밀번호를 그냥 내보내기 하면 되는 것 아닌가?
https://support.microsoft.com/en-us/topic/export-passwords-i...- 비밀번호 관리자는 메모리 안의 비밀번호를 안전하게 유지하려고 꽤 많은 수고를 하는 경우가 많지만, 그런 도구들의 공격 모델이 잘 이해되지 않을 때가 많음
예를 들어 KeePass 같은 도구는 브라우저 플러그인을 등록하는 데 꽤 신경 쓰지만, 일반 사용자 권한만 있으면 브라우저에서 그 키를 뽑아내 뭐든 할 수 있음
웹 앱의 “이 브라우저 신뢰” 같은 방식도 쿠키 저장소를 쉽게 읽을 수 있다면 이상하게 느껴짐
- 비밀번호 관리자는 메모리 안의 비밀번호를 안전하게 유지하려고 꽤 많은 수고를 하는 경우가 많지만, 그런 도구들의 공격 모델이 잘 이해되지 않을 때가 많음
- Linux의 PAM에도 비슷한 일을 할 수 있을 듯함. gdb를 openssh나 getty 로그인 프로세스에 붙이면 됨
- 이 .exe의 소스 코드 링크가 있나? 어떻게 추출하는지 보고 싶음
- 진짜 실수는 아직도 단순 비밀번호 인증을 쓰고 있다는 점임. 챌린지-응답이나 공개키 인증을 써야 함
- 공평하게 말하면, 메모리에 로드한다는 것과 저장한다는 건 같은 말이 아님
- 제목에는 “메모리에 저장”이라고 되어 있는데, 내겐 거의 같은 말처럼 들림. 메모리에 “로드”하는 것과 “저장”하는 것의 차이를 어떻게 보는지 설명해줄 수 있나?
- 틀렸다면 고쳐주길 바라지만, Chrome도 Windows에서 비밀번호를 원시 텍스트로 보관하고 있었거나 적어도 예전엔 그랬음. 2021년 버전 Chrome에서 친구가 잊어버린 비밀번호를 꺼낸 적이 있음
- 몇 년 전 일이긴 하지만, Google 개발자들이 로컬 파일 시스템에 접근할 수 있으면 이미 끝난 거라고 말하며 논쟁하던 걸 본 기억이 있음
- Chrome은 2024년에 쿠키 파일에 앱 바인딩 암호화를 추가했음