▲

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

 (news.ycombinator.com)
1P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • AWS 장애 이후 사용자의 계정 보안이 심각하게 침해된 경험임
  • 예기치 않은 서비스 중단이 계정의 취약점 노출로 이어졌음
  • 사용자는 AWS 계정 접속 내역에서 이상 징후를 발견함
  • 계정 탈취로 인해 중요한 데이터와 비용 손실 등이 발생함
  • 커뮤니티에 유사 사례와 대응 방안에 대한 조언을 요청하는 상황임

AWS 장애 이후 계정 침해 사례

최근 AWS에서 발생한 서비스 장애 이후, 한 사용자가 자신의 AWS 계정이 외부 공격자에 의해 탈취되는 사고를 겪음

침해 경로 및 문제 상황

  • 장애 기간 중 일부 보안 정책이 정상적으로 동작하지 못할 수도 있다는 점이 언급됨
  • 공격자는 장애 이후 계정 로그에 비정상적 접근 흔적을 남겼으며, 일부 리소스가 예기치 않게 생성/삭제되는 현상 발생함
  • 사용자는 장애와 함께 권한 변경 또는 인증정보 노출 가능성에 대한 우려를 표시함

피해 및 대응

  • 비용 증가, 데이터 유출 등 실질적 피해가 발생함
  • AWS 지원팀에 연락하여 사건 내역 및 대응 방법을 문의함
  • 커뮤니티에서는 2차 인증 활성화, ** 역할 기반 접근권한 최소화** 등 사전 예방의 중요성을 강조함

커뮤니티 요청

  • 동일한 경험이나 유사 사례가 있는 다른 AWS 이용자들의 조언을 구함
  • 효과적인 보안 대응 전략 및 사후 복구 방법 공유 희망
▲
GN⁺ 9시간전  [-]
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나 자격증명을 공유하는 언급은 삼가야 함. 누군가는 진심으로 받아들일 수도 있으니 주의가 필요함
답변달기