LastPass 소스 코드 위반 – 사고 대응 보고서 발표

플라톤에 의해 재발행

팔로워 : 0

이달의 빅스토리가 될 것 같다면 우버의 데이터 유출, 해커가 차량 공유 회사의 네트워크를 통해 광범위하게 로밍할 수 있었던 곳…

..지난 달의 큰 이야기는 LastPass 위반, 공격자는 분명히 LastPass 네트워크의 한 부분에만 액세스할 수 있었지만 회사의 독점 소스 코드를 사용하여 만회할 수 있었습니다.

다행스럽게도 Uber의 공격자는 스크린샷을 캡처하고 이를 온라인에 널리 퍼뜨리고 다음과 같은 외치는 메시지로 회사를 조롱하여 크고 빠른 PR을 하기로 결심한 것 같습니다. UBER가 해킹당했습니다, 자체 Slack 및 버그 바운티 포럼에서:

그러나 LastPass의 공격자는 더 은밀하게 작동하는 것으로 보이며, 분명히 LastPass 개발자를 속여 악성코드를 설치하도록 한 다음 사이버 범죄자가 회사의 소스 코드 리포지토리에 차를 몰아넣는 데 사용했습니다.

LastPass는 이제 공식 후속 보고서 공격 및 침입 여파에 대한 공격자에 대해 알아낼 수 있었던 것을 기반으로 사건에 대해.

LastPass 기사는 귀하가 LastPass 사용자가 아니더라도 읽을 가치가 있다고 생각합니다. 좋은 사고 대응 보고서는 귀하가 어떤 사람인지 파악할 수 없다는 것을 인정하는 것만큼 유용하다는 것을 상기시키기 때문입니다.

지금 우리가 알고 있는 것

아래 굵게 표시된 문장은 LastPass가 말하는 내용의 개요를 제공합니다.

공격자 "개발자의 손상된 엔드포인트를 사용하여 [개발] 환경에 대한 액세스 권한을 얻었습니다." 우리는 이것이 프로그래머의 컴퓨터에 시스템 스누핑 맬웨어를 이식한 공격자가 내린 것이라고 가정합니다.
맬웨어를 삽입하는 데 사용된 트릭을 확인할 수 없습니다. 마지막 공격이 실제로 어떻게 수행되었는지 알면 수정된 예방, 탐지 및 대응 절차가 다음에 이를 차단할 가능성이 있음을 고객에게 더 쉽게 안심시킬 수 있기 때문에 실망스럽습니다. 패치되지 않은 로컬 소프트웨어, 안전하지 않은 로컬 구성으로 이어지는 "섀도우 IT", 피싱 클릭 실수, 안전하지 않은 다운로드 습관, 관련 코더가 의존하는 소스 코드 공급망의 배신, 또는 부비 트랩된 이메일 첨부 파일을 잘못 열었습니다. "알려진 미지"에 해당하는 것을 인정한 LastPass에 감사드립니다.
공격자 "개발자가 다단계 인증을 사용하여 성공적으로 인증한 후 영구 액세스를 사용하여 개발자를 가장했습니다." 이것은 해커가 피해자의 비밀번호나 2FA 코드를 획득할 필요가 없었지만 단순히 쿠키 훔치기 공격, 또는 프로그래머의 일반적인 액세스를 피기백하기 위해 실제 네트워크 트래픽(또는 피해자 컴퓨터의 RAM)에서 개발자의 인증 토큰을 추출했습니다.

LastPass는 침입을 즉시 알아차리지 못했지만 XNUMX일 이내에 공격자를 탐지하고 추방했습니다. 위험에 대한 최근 기사에서 언급했듯이 타임스탬프 모호성 시스템 로그에서 공격 중 이벤트가 발생한 정확한 순서를 결정할 수 있는 것은 사고 대응의 중요한 부분입니다.

LastPass는 개발 및 생산 네트워크를 물리적으로 분리된 상태로 유지합니다. 이것은 개발 네트워크에 대한 공격(변화와 실험이 불가피한 상태에 있음)이 고객과 나머지 비즈니스가 직접 사용할 수 있는 공식 소프트웨어의 즉각적인 손상으로 바뀌는 것을 방지하기 때문에 좋은 사이버 보안 관행입니다. .
LastPass는 개발 환경에 고객 데이터를 보관하지 않습니다. 다시 말하지만, 개발자는 작업 이름에서 알 수 있듯이 일반적으로 아직 완전한 보안 검토 및 품질 보증 프로세스를 거치지 않은 소프트웨어에서 작업하고 있다는 점을 감안할 때 이는 좋은 관행입니다. 이러한 분리는 또한 LastPass가 암호 볼트 데이터(어쨌든 사용자의 개인 키로 암호화되었을 것)가 노출될 수 없다고 주장하는 것을 믿을 수 있게 하며, 이는 단순히 “우리는 노출됐다”고 말했다. 또한 실제 데이터를 개발 네트워크에서 제외하면 선의의 코더가 규제 보호를 받을 데이터를 실수로 가져와 비공식 테스트 목적으로 사용하는 것을 방지할 수 있습니다.
소스 코드가 도난당했지만 공격자가 무단으로 코드를 변경한 것은 없습니다. 물론 우리는 계속해야 할 LastPass 자신의 주장만 가지고 있지만 나머지 사건 보고서의 스타일과 어조를 고려할 때 회사의 말을 그대로 받아들이지 않을 이유가 없습니다.
개발 네트워크에서 프로덕션으로 이동하는 소스 코드 "엄격한 코드 검토, 테스트 및 검증 프로세스를 완료한 후에만 가능". 이것은 LastPass가 수정되거나 오염된 소스 코드가 고객이나 비즈니스의 나머지 부분에 도달하지 않았을 것이라고 주장하는 것을 믿을 수 있게 합니다. 공격자가 악성 코드를 삽입하더라도 버전 관리 시스템에서..
LastPass는 사용자의 개인 암호 해독 키를 저장하거나 알지도 못합니다. 즉, 공격자가 암호 데이터를 사용하더라도, 그것은 너무 많은 갈가리 찢긴 디지털 양배추로 끝났을 것입니다. (LastPass는 또한 공개 설명 클라이언트 측 PBKDF2-HMAC-SHA256을 사용하여 100,100번의 반복으로 오프라인 비밀번호를 해싱하고 확장하는 것을 포함하여 오프라인 크래킹에 대해 비밀번호 보관소 데이터를 보호하는 방법에 대해 설명합니다. 암호 크래킹 시도 공격자가 암호 저장소의 로컬에 저장된 복사본을 사용하더라도 훨씬 더 어렵습니다.)