AWS 장애 이후 계정이 탈취되었습니다

Hacker News 의견

• 보통 이런 일은 우연이라고 생각하겠지만, 나도 클라이언트 계정이 침해당한 사례가 있었음. 고객은 소규모 조직이었고, 5년 넘게 사용하지 않던 두 개의 오래된 IAM 계정에서 갑작스럽게 콘솔 로그인 및 비밀번호 변경 이력이 생겼음. 조사 결과, 현재까지 밝혀진 건 AWS SES 프로덕션 접근 활성화와 하루 이메일 한도 5만 건 상향을 위한 지원 티켓을 남긴 것이 전부였음. 5년 이상 휴면이던 계정이 딱 이 시점에 활동한 것이 너무 이상함

  • 피싱 공격 냄새가 남. 예를 들어 AWS 장애 공지를 가장한 이메일을 받고, 콘솔 로그인 유도 후 악의적 래퍼를 통해 인증하면 계정 보안이 뚫릴 수 있음
  • 거의 똑같은 일을 1년 전에 직접 겪었음. 아주 오래된 계정으로 로그인, SES 접근 후 이메일 한도 상향 요청. 우리가 빨리 대응할 수 있었던 건 한도 상향 티켓이 필수였기 때문임. 만약 아직 확인하지 않았다면 새로 만들어진 Roles도 체크 필요함. 우리는 즉시 침해 계정을 정리했는데, 내가 전반적으로 Roles를 확인하며 한 달 미만이거나 admin 권한이 있는 것들을 다 제거함. 한편으로는 침해가 실제로 내 키에서 시작됐다는 사실도 확인했음. 처음 사용자가 생성된 시점이 실제 SES 요청보다 거의 한 달 전이었고, 공격자가 이미 우리를 침해한 상태에서 AWS 장애가 터지자 이 기회를 노린 것일 수도 있음. 다른 AWS 문제와 섞여서 잘 안 보이게 말임

• 이미 접근 권한을 얻은 사람이 AWS 인프라의 혼란 같은 사건이 터지길 기다리다가, 그 시점에 공격을 감행해 혼란에 숨어들 가능성이 있지 않을까 싶음. 몇 주 혹은 몇 달 전에 토큰이 노출됐더라도, 바로 행동하지 않고 큰 사건이 있을 때까지 기다리는 전략일 수 있음. 만약 내가 공격자라면 이런 방법을 써보고 싶을 것 같음

  • 당연히 가능함. 실사 담당자로서도 이런 사례 실제로 들음. 공격자들은 사전에 준비 다 해놓고 회사 매각 등 중요한 이벤트가 올 때까지 기다렸다가 움직이기도 함. 고도화된 공격자일수록 이런 기회를 노려 선제적으로 준비함
  • 같은 팀 출신임을 밝히면서, 실제로 오늘 악용된 키와 관련된 경고성 이메일을 2년 전에 무작위 사람에게서 받은 적 있었음. 그러나 어제까지는 아무런 악용이 없었음
  • 오히려 이런때가 공격에는 나쁜 타이밍일 것 같음. 다들 지금 AWS에 주목하고 있고 많이 로그인하고 있기에 이상한 점이 있으면 더 민감하게 볼 거라 생각함. 우리 회사가 AWS를 쓴다면, 이런 상황에서 더더욱 모든 걸 예의주시할 것임

• 만약 내가 공격자라면 언제 공격할지 고를 텐데, 로그 집계도 제대로 되지 않는 큰 장애 상황이 좋은 기회일 수 있음. 실제로 이미 침해당한 상황에서 이 시점에 악용했거나, 혹은 AWS 장애에 편승하여 내 리소스로 다른 공격을 감행했을 수도 있음

• 클라우드 환경에서 뭔가 이상한 리소스(EC2 등)가 생성된다면 그것이 어떤 이벤트로 생겼는지 CloudTrail에서 확인할 수 있음. 대표적으로 runinstance 이벤트를 보면 될 것임

  • 요즘 AWS는 안써서 직접 콘솔은 확인 못하지만, 만약 비슷한 일을 겪는다면 대략 다음 단계를 추천함:
    1. EC2를 만든 계정/주체를 확인 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
    2. userIdentity 기준으로 후속 액션 추적
    3. 콘솔 직접 로그인 이력 확인 (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
    4. Security Token Service로 인증 요청 이력 확인 (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
    5. STS 세션을 통한 AssumeRole 사용 여부 확인 (eventSource:sts.amazonaws.com, eventName:AssumeRole)
    6. 새 IAM Role/Account 생성 등 영속성 유지를 위한 시도 확인 (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
    7. 기존 Role/Account가 더 높은 권한으로 수정되었는지 확인 (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
    8. Access Key 생성/삭제 이력 확인 (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
    9. 프로덕션 EC2의 IAMInstanceProfile 변경으로 백도어 가능성 점검 (자세한 레퍼런스는 AWS Docs 샘플 참고) 만약 더 깊은 침해가 의심된다면, 전문가의 환경 점검 및 감사를 받아보는 것을 추천함
  • 좋은 정보라서 로그를 찾아볼 예정임. 추가로 관찰한 점을 나열하자면:
    1. 루트 계정 아래 20여 개 조직이 생성되었고 모두 같은 도메인(co.jp) 이메일 주소를 사용함
    2. 공격자가 여러 개의 fargate 템플릿을 만들어둠
    3. 16~17개 AWS 지역에 자원을 생성함
    4. SES, WS Fargate 리소스 할당량 증가 요청, SageMaker 노트북 유지관리 요청 등 불필요한 리소스 요청 발생(이에 대한 알림 이메일 여러 건 수신)
    5. 몇몇 이메일에서 새로운 이름(랜덤 네임@outlook.com)이 추가되는 걸 발견함
  • RunInstances 이벤트가 바로 그 이벤트임

• 몇몇 레딧 이용자들이 AWS 장애 중 새로고침을 하다가 전혀 다른 사용자로 잠시 로그인되는 경험을 했었다고 함

  • 예전에 내가 일했던 회사에서도 비슷한 일이 있었음. 고객들이 서로 다른 고객 데이터에 접속하게 되는 현상이었는데, 원인은 실시간 프로덕션 환경에서 라이브 디버깅을 시도한 잘못된 직원 때문이었음(면접 때 채용 반대 의견을 냈었는데 말임). 이런 문제는 추적하고 해결하는 게 정말 힘들었음
  • 혹시 장애 시간대에 DynamoDB가 일시적 불일치 상태가 되면서, IAM 자격증명까지 꼬인 것은 아닐지 의심됨. 사실이라면 정말 심각한 문제임. 관련 사례 참고할 만한 링크 있나 궁금함
  • 관련 증거가 있으면 공유 부탁함. 정말 충격적임
  • 최근에 ChatGPT도 비슷한 이슈가 있지 않았는지 생각남. 뭔가 유사한 느낌임
  • 이런 보안 사고는 단순한 서비스 일시 장애 문제와는 비교도 안 되게 심각한 사안임

• 평상시라면 이런 사건은 단순한 우연이겠지만, 대체로 노출된 access key가 원인임. MFA 미적용 콘솔 계정의 비밀번호 노출로 인한 문제도 있긴 한데 조금 더 드문 경우임

• 패닉 상황에는 사람들이 피싱 공격에 가장 취약해짐. 전면적으로 비밀번호를 재설정하고 AWS 담당자에게 상황을 알려야 함. 보통 신뢰 기반으로 잘 풀어줌

• us-east-1 리전은 상상 이상으로 큼. 최근 공개된 정보 기준 159개의 데이터센터가 있다고 함. 수백만 계정이 여기에 집중되어 있을 수도 있음. 이 현상이 AWS 장애와 연결되었을 수도 있지만, 개인적으로는 우연일 가능성이 더 높다고 생각함

  • 159개라니 놀라움. 참고할 만한 출처 있으면 공유해줬으면 함

• 이상하게 들리겠지만, 혹시 API key 보내주면 유출 리스트에 있는지 확인해볼 수 있을 것 같음

  • 농담인 건 알지만, 그래도 중요한 얘기를 싶어 조심스럽게 알림. 농담일지라도 API key나 자격증명을 공유하는 언급은 삼가야 함. 누군가는 진심으로 받아들일 수도 있으니 주의가 필요함