LastPass가 또 다른 데이터 유출을 사용자에게 통지함
(9to5mac.com)- LastPass 사용자는 외부 파트너 Klue 침해 사고로 개인 데이터와 지원 케이스 데이터가 노출됐다는 통지를 받음
- 이번 사고의 접근 범위는 표준 비즈니스 연락처 정보, CRM 데이터, 지원 케이스 데이터, 영업 관련 데이터로 제한됐으며 비밀번호 금고는 영향받지 않음
- 노출 항목에는 고객 이름, 전화번호, 이메일 주소, 실제 주소가 포함되고, Klue 플랫폼은 Salesforce와 Gong 시스템에 통합돼 있음
- 사고 인지 후 LastPass는 직원의 Klue 접근을 취소하고 노출된 API 토큰을 교체했으며, 법 집행기관 통지와 Klue·Salesforce를 통한 조사를 진행함
- 유출된 연락처 정보는 피싱과 사회공학 공격에 악용될 수 있어, 고객과 기업은 공유된 공격 지표를 확인할 필요가 있음
Klue 침해 사고와 LastPass 대응
- 시장조사 기업 Klue에서 발생한 침해 사고의 영향으로 LastPass가 해당 사용자에게 이메일을 발송함
- 해커는 침해를 통해 고객 정보와 지원 케이스 데이터에 접근할 수 있었음
- 접근된 정보는 다음 범위로 제한됨
- 고객 이름, 전화번호, 이메일 주소, 실제 주소
- 고객 관계 관리(CRM) 데이터
- 지원 케이스 데이터
- 영업 관련 데이터
- 이번 사고에서 LastPass의 비밀번호 금고는 영향받지 않음
- Klue 플랫폼은 Salesforce 및 Gong 시스템과 통합돼 있음
- LastPass는 사고 대응으로 접근 차단과 조사 절차를 진행함
- 직원의 Klue 접근 권한 취소
- 노출된 API 토큰 교체
- 법 집행기관 통지
- Klue 및 Salesforce 접촉을 통한 사고 범위 조사
공격 지표와 과거 보안 사고
- 고객은 유출 정보를 활용한 피싱 공격 또는 사회공학 시도에 주의해야 함
- 기업이 관련 활동을 시스템에서 검색할 수 있도록 공격자 관련 지표가 공유됨
- IP 주소:
138.226.246[.]9494.154.32[.]160159.183.215[.]61159.183.181[.]239
- 이메일 발신 도메인:
baccarat.com[.]aurobinskitchen.com[.]auhouse.com[.]au
- IP 주소:
- LastPass는 과거에도 여러 차례 보안 사고를 겪음
- 2015년에는 계정 이메일 주소, 비밀번호 힌트, 인증 해시, 암호화 솔트가 탈취됐으나 암호화된 금고 데이터에는 접근이 없었음
- 2022년에는 공격자가 개발자 계정을 침해해 소스 코드와 기술 정보를 훔쳤고, 이후 이를 이용해 고객 기록과 암호화된 비밀번호 금고가 포함된 클라우드 백업에 접근함
- 같은 2022년 사고에는 이름, 청구 주소, 이메일 주소, 전화번호 같은 비암호화 정보도 포함됨
댓글과 토론
Hacker News 의견들
-
이제 누가 LastPass를 진지하게 신뢰할 수 있는지 모르겠음
몇 년 전 은행 데이터를 다루는 회사에서 일했는데, 이전 LastPass 보안 사고 직후에도 계속 LastPass를 쓰고 있었고 이전할 계획도 없었음- 많은 사람과 조직은 보안 제품을 보안을 위해 쓰는 게 아니라 보안 연극을 위해 씀
대다수 사람들, 심지어 보안 담당자 중에도 이번 침해를 못 들을 사람이 많을 테니, LastPass는 그들에게는 여전히 잘 작동하는 셈임 - 비밀번호가 아직 알려지지 않았다면 그 “침해”는 최종 사용자 입장에서는 실패가 아님
금고의 마스터 비밀번호가 안전하고, 금고에 접근하는 유일한 방법이 여전히 마스터 비밀번호뿐이라면 최종 사용자가 원하는 기능은 하고 있는 것임
“침해”라는 말은 조건을 붙이지 않으면 의미가 없음 - 수백 개 회사에 보안 컨설팅을 많이 해봤는데, 실제로 보안을 진지하게 받아들이는 회사는 과거에 침해를 겪은 회사였음
경영진과 이사회가 비용 영향을 직접 보기 전, 단지 읽기만 해서는 보안 프로그램에 필요한 예산이 절대 붙지 않음
그렇다고 그 이유로 LastPass를 추천한다는 뜻은 아니지만, 그 이유만으로 완전히 배제하지는 않겠음 - 모든 비밀번호와 암호화 키를 제3자에게 맡기는 걸 어떻게 신뢰하는지 이해가 안 됨
KeePassXC 설정은 아주 간단함
- 많은 사람과 조직은 보안 제품을 보안을 위해 쓰는 게 아니라 보안 연극을 위해 씀
-
영향을 받은 회사가 훨씬 더 많음. 아래에도 일부가 나열돼 있음
"Klue has not said how many of its hundreds of customers are affected. Several companies have come forward to confirm they had data stolen during the attack, including Gong, Jamf, HackerOne, Insurity, OneTrust, Recorded Future, Snyk, Sprout Social, and Tanium."
Cybercrime group Icarus took credit for the breach, saying on its leak site that it will publish the stolen data on Monday if the company does not pay the hackers’ ransom."
https://techcrunch.com/2026/06/22/klue-hack-results-in-data-... -
LastPass가 대체 왜 고객 세부 정보를 시장 조사 회사에 넘기고 있는 건지 모르겠음
그런 데이터는 이름, 구체적 주소 등을 빼고 완전히 익명화했어야 함
추천을 찾는 사람에게는 KeepassXC와 Keepass2Android를 씀. 오픈소스이고, 로컬 데이터베이스를 쓰며 동기화 여부를 직접 고를 수 있음. 나는 Own cloud로 동기화함- 나는 몇 년째 pwsafe를 쓰고 있음
역시 무료 오픈소스이고 로컬 전용 금고임. 무능하게 데이터를 잃어버릴 클라우드 서비스에 의존하지 않아도 됨
선택적으로 금고를 Dropbox나 iCloud Drive에 저장할 수는 있지만, 굳이 왜 그래야 하는지 모르겠음 -
Any such data should have been fully anonymized: no names, no specific addresses, etc..
애초에 왜 그런 데이터를 넘겨야 함?
- 나는 몇 년째 pwsafe를 쓰고 있음
-
https://blog.lastpass.com/posts/klue-supply-chain-incident-a...
The information accessed was limited to standard business contact information and related customer relationship management (CRM) data, including customer names, phone numbers, email addresses, and physical addresses, as well as support case data and sales-related data.
-
이 방식도 어떤 면에서는 LastPass를 쓰는 것보다 더 나쁠 수 있겠지만, 지난 몇 년 동안 비밀번호의 90%는 그냥 생성하고 잊어버림
나머지 10%만 비밀번호 관리자에 보관함. 별로 중요하지 않은 서비스라면 로그인할 때마다 “비밀번호를 잊어버림”으로 새 비밀번호를 만들고 바꿈- 계정에 2단계 인증이 없으면 이 방식이 통함
마지막 사이드 프로젝트 앱에서는 사용자가 이메일 일회용 비밀번호로만 로그인할 수 있었음
가짜 사이트에 일회용 비밀번호를 입력하게 만드는 피싱 같은 보안 단점은 있지만, 민감한 걸 저장하지 않는 앱이라서 큰 보안 위험은 아니라고 봄 - 예전 전화번호에 더 이상 접근할 수 없는데, 그 번호로 2단계 인증 문자가 가게 되어 곤란했던 적이 있음
- 그래서 많은 서비스가 로그인 방식으로 이메일 매직 링크를 쓰는 쪽으로 옮겨감
결국 많은 서비스에서는 이메일을 장악하는 것이 사실상 로그인을 장악하는 것임
- 계정에 2단계 인증이 없으면 이 방식이 통함
-
나는 평생 라이선스를 싸게 산 덕분에 몇 년째 Enpass를 쓰고 있음
Enpass는 비밀번호 동기화를 위한 클라우드 서비스를 직접 호스팅하지 않고, 사용자가 클라우드 저장소에 인증하면 거기로 동기화함. 나는 Google Drive를 씀
이 접근이 더 낫다고 봄. 악의적인 누군가가 내 Google 계정에 들어오면 어차피 끝장이고, 아마 비밀번호 관리자에 들어온 것보다 더 나쁠 수 있음
게다가 중앙 한곳에 침해당하면 대박인 데이터 더미를 만들지 않음. Enpass의 모든 비밀번호를 털려면 Google Drive, Dropbox, iCloud 등을 모두 해킹한 뒤 파일을 수동으로 찾아야 함- 그게 예를 들어 KeePass와 어떻게 다른가?
-
또 다른 침해 때문에 LastPass를 집단적으로 욕하고, 고객 데이터를 제3자에게 넘기다니 완전히 무책임하다고 하는 건 재미있지만, 실제로 무슨 일이 있었는지 잠깐만 보면 머릿속 이야기와 현실이 꽤 다르다는 걸 알 수 있음
Klue는 많은 영업팀이 쓰는 고객 관계 관리 서비스 중 하나임. 고객 연락처 이메일, 재무팀 같은 고객 기록을 넘겨야 Klue가 그 고객에 대한 “시장 정보” 같은 걸 제공함
영업팀에 가서 시스템에 연결해둔 잡다한 것들을 보면 비슷한 걸 찾을 가능성이 큼
이게 좋은 생각인지와는 별개로, 나는 강하게 싫어하지만, 요즘 영업팀은 이렇게 일함. 빼앗으려 하면 영업 조직 전체와 싸우게 됨
오히려 이런 침해가 더 자주 일어나지 않는 게 놀라움
LastPass의 실제 비밀번호 데이터베이스에는 영향이 없음
관련된 어느 조직과도 관계 없음-
I am more surprised that these breaches don't happen more often.
실제로는 자주 일어남
-
-
이제 LastPass는 First0wned로 리브랜딩할 때가 된 것 같음
-
금고가 유출된 뒤에도 LastPass를 계속 쓰거나 새로 도입한 회사라면, 이번 건은 그냥 CRM 데이터라서 전혀 신경 쓰지 않을 것 같음
LastPass를 계속 쓰는 회사에 어느 정도는 공감함. 조직을 LastPass에서 1Password로 옮겨야 했을 때 엄청난 작업이었고 정말 성가셨음
하지만 2022년 이후에도 LastPass를 선택한 사람에게는 공감하기 어려움- 여기서 별일 아닌 부분은 데이터의 중요도가 낮다는 것임
진짜 핵심은 아무리 사소해도 LastPass라면 더 잘했어야 한다는 데 있음
비밀번호 저장 회사라면 신뢰받기 위해 이 정도보다 나아야 함
- 여기서 별일 아닌 부분은 데이터의 중요도가 낮다는 것임
-
오래전에 LastPass를 버리고 BitWarden으로 옮겼지만, 지금은 대체로 Apple의 Passwords 앱을 씀