보통 이런 일은 우연이라고 생각하겠지만, 나도 클라이언트 계정이 침해당한 사례가 있었음. 고객은 소규모 조직이었고, 5년 넘게 사용하지 않던 두 개의 오래된 IAM 계정에서 갑작스럽게 콘솔 로그인 및 비밀번호 변경 이력이 생겼음. 조사 결과, 현재까지 밝혀진 건 AWS SES 프로덕션 접근 활성화와 하루 이메일 한도 5만 건 상향을 위한 지원 티켓을 남긴 것이 전부였음. 5년 이상 휴면이던 계정이 딱 이 시점에 활동한 것이 너무 이상함
피싱 공격 냄새가 남. 예를 들어 AWS 장애 공지를 가장한 이메일을 받고, 콘솔 로그인 유도 후 악의적 래퍼를 통해 인증하면 계정 보안이 뚫릴 수 있음
거의 똑같은 일을 1년 전에 직접 겪었음. 아주 오래된 계정으로 로그인, SES 접근 후 이메일 한도 상향 요청. 우리가 빨리 대응할 수 있었던 건 한도 상향 티켓이 필수였기 때문임. 만약 아직 확인하지 않았다면 새로 만들어진 Roles도 체크 필요함. 우리는 즉시 침해 계정을 정리했는데, 내가 전반적으로 Roles를 확인하며 한 달 미만이거나 admin 권한이 있는 것들을 다 제거함. 한편으로는 침해가 실제로 내 키에서 시작됐다는 사실도 확인했음. 처음 사용자가 생성된 시점이 실제 SES 요청보다 거의 한 달 전이었고, 공격자가 이미 우리를 침해한 상태에서 AWS 장애가 터지자 이 기회를 노린 것일 수도 있음. 다른 AWS 문제와 섞여서 잘 안 보이게 말임
이미 접근 권한을 얻은 사람이 AWS 인프라의 혼란 같은 사건이 터지길 기다리다가, 그 시점에 공격을 감행해 혼란에 숨어들 가능성이 있지 않을까 싶음. 몇 주 혹은 몇 달 전에 토큰이 노출됐더라도, 바로 행동하지 않고 큰 사건이 있을 때까지 기다리는 전략일 수 있음. 만약 내가 공격자라면 이런 방법을 써보고 싶을 것 같음
당연히 가능함. 실사 담당자로서도 이런 사례 실제로 들음. 공격자들은 사전에 준비 다 해놓고 회사 매각 등 중요한 이벤트가 올 때까지 기다렸다가 움직이기도 함. 고도화된 공격자일수록 이런 기회를 노려 선제적으로 준비함
같은 팀 출신임을 밝히면서, 실제로 오늘 악용된 키와 관련된 경고성 이메일을 2년 전에 무작위 사람에게서 받은 적 있었음. 그러나 어제까지는 아무런 악용이 없었음
오히려 이런때가 공격에는 나쁜 타이밍일 것 같음. 다들 지금 AWS에 주목하고 있고 많이 로그인하고 있기에 이상한 점이 있으면 더 민감하게 볼 거라 생각함. 우리 회사가 AWS를 쓴다면, 이런 상황에서 더더욱 모든 걸 예의주시할 것임
만약 내가 공격자라면 언제 공격할지 고를 텐데, 로그 집계도 제대로 되지 않는 큰 장애 상황이 좋은 기회일 수 있음. 실제로 이미 침해당한 상황에서 이 시점에 악용했거나, 혹은 AWS 장애에 편승하여 내 리소스로 다른 공격을 감행했을 수도 있음
클라우드 환경에서 뭔가 이상한 리소스(EC2 등)가 생성된다면 그것이 어떤 이벤트로 생겼는지 CloudTrail에서 확인할 수 있음. 대표적으로 runinstance 이벤트를 보면 될 것임
요즘 AWS는 안써서 직접 콘솔은 확인 못하지만, 만약 비슷한 일을 겪는다면 대략 다음 단계를 추천함:
EC2를 만든 계정/주체를 확인 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
userIdentity 기준으로 후속 액션 추적
콘솔 직접 로그인 이력 확인 (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
Security Token Service로 인증 요청 이력 확인 (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
STS 세션을 통한 AssumeRole 사용 여부 확인 (eventSource:sts.amazonaws.com, eventName:AssumeRole)
새 IAM Role/Account 생성 등 영속성 유지를 위한 시도 확인 (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
기존 Role/Account가 더 높은 권한으로 수정되었는지 확인 (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
Access Key 생성/삭제 이력 확인 (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
프로덕션 EC2의 IAMInstanceProfile 변경으로 백도어 가능성 점검 (자세한 레퍼런스는 AWS Docs 샘플 참고)
만약 더 깊은 침해가 의심된다면, 전문가의 환경 점검 및 감사를 받아보는 것을 추천함
좋은 정보라서 로그를 찾아볼 예정임. 추가로 관찰한 점을 나열하자면:
루트 계정 아래 20여 개 조직이 생성되었고 모두 같은 도메인(co.jp) 이메일 주소를 사용함
공격자가 여러 개의 fargate 템플릿을 만들어둠
16~17개 AWS 지역에 자원을 생성함
SES, WS Fargate 리소스 할당량 증가 요청, SageMaker 노트북 유지관리 요청 등 불필요한 리소스 요청 발생(이에 대한 알림 이메일 여러 건 수신)
몇몇 이메일에서 새로운 이름(랜덤 네임@outlook.com)이 추가되는 걸 발견함
RunInstances 이벤트가 바로 그 이벤트임
몇몇 레딧 이용자들이 AWS 장애 중 새로고침을 하다가 전혀 다른 사용자로 잠시 로그인되는 경험을 했었다고 함
예전에 내가 일했던 회사에서도 비슷한 일이 있었음. 고객들이 서로 다른 고객 데이터에 접속하게 되는 현상이었는데, 원인은 실시간 프로덕션 환경에서 라이브 디버깅을 시도한 잘못된 직원 때문이었음(면접 때 채용 반대 의견을 냈었는데 말임). 이런 문제는 추적하고 해결하는 게 정말 힘들었음
혹시 장애 시간대에 DynamoDB가 일시적 불일치 상태가 되면서, IAM 자격증명까지 꼬인 것은 아닐지 의심됨. 사실이라면 정말 심각한 문제임. 관련 사례 참고할 만한 링크 있나 궁금함
관련 증거가 있으면 공유 부탁함. 정말 충격적임
최근에 ChatGPT도 비슷한 이슈가 있지 않았는지 생각남. 뭔가 유사한 느낌임
이런 보안 사고는 단순한 서비스 일시 장애 문제와는 비교도 안 되게 심각한 사안임
평상시라면 이런 사건은 단순한 우연이겠지만, 대체로 노출된 access key가 원인임. MFA 미적용 콘솔 계정의 비밀번호 노출로 인한 문제도 있긴 한데 조금 더 드문 경우임
패닉 상황에는 사람들이 피싱 공격에 가장 취약해짐. 전면적으로 비밀번호를 재설정하고 AWS 담당자에게 상황을 알려야 함. 보통 신뢰 기반으로 잘 풀어줌
us-east-1 리전은 상상 이상으로 큼. 최근 공개된 정보 기준 159개의 데이터센터가 있다고 함. 수백만 계정이 여기에 집중되어 있을 수도 있음. 이 현상이 AWS 장애와 연결되었을 수도 있지만, 개인적으로는 우연일 가능성이 더 높다고 생각함
159개라니 놀라움. 참고할 만한 출처 있으면 공유해줬으면 함
이상하게 들리겠지만, 혹시 API key 보내주면 유출 리스트에 있는지 확인해볼 수 있을 것 같음
농담인 건 알지만, 그래도 중요한 얘기를 싶어 조심스럽게 알림. 농담일지라도 API key나 자격증명을 공유하는 언급은 삼가야 함. 누군가는 진심으로 받아들일 수도 있으니 주의가 필요함
Hacker News 의견
보통 이런 일은 우연이라고 생각하겠지만, 나도 클라이언트 계정이 침해당한 사례가 있었음. 고객은 소규모 조직이었고, 5년 넘게 사용하지 않던 두 개의 오래된 IAM 계정에서 갑작스럽게 콘솔 로그인 및 비밀번호 변경 이력이 생겼음. 조사 결과, 현재까지 밝혀진 건 AWS SES 프로덕션 접근 활성화와 하루 이메일 한도 5만 건 상향을 위한 지원 티켓을 남긴 것이 전부였음. 5년 이상 휴면이던 계정이 딱 이 시점에 활동한 것이 너무 이상함
이미 접근 권한을 얻은 사람이 AWS 인프라의 혼란 같은 사건이 터지길 기다리다가, 그 시점에 공격을 감행해 혼란에 숨어들 가능성이 있지 않을까 싶음. 몇 주 혹은 몇 달 전에 토큰이 노출됐더라도, 바로 행동하지 않고 큰 사건이 있을 때까지 기다리는 전략일 수 있음. 만약 내가 공격자라면 이런 방법을 써보고 싶을 것 같음
만약 내가 공격자라면 언제 공격할지 고를 텐데, 로그 집계도 제대로 되지 않는 큰 장애 상황이 좋은 기회일 수 있음. 실제로 이미 침해당한 상황에서 이 시점에 악용했거나, 혹은 AWS 장애에 편승하여 내 리소스로 다른 공격을 감행했을 수도 있음
클라우드 환경에서 뭔가 이상한 리소스(EC2 등)가 생성된다면 그것이 어떤 이벤트로 생겼는지 CloudTrail에서 확인할 수 있음. 대표적으로 runinstance 이벤트를 보면 될 것임
몇몇 레딧 이용자들이 AWS 장애 중 새로고침을 하다가 전혀 다른 사용자로 잠시 로그인되는 경험을 했었다고 함
평상시라면 이런 사건은 단순한 우연이겠지만, 대체로 노출된 access key가 원인임. MFA 미적용 콘솔 계정의 비밀번호 노출로 인한 문제도 있긴 한데 조금 더 드문 경우임
패닉 상황에는 사람들이 피싱 공격에 가장 취약해짐. 전면적으로 비밀번호를 재설정하고 AWS 담당자에게 상황을 알려야 함. 보통 신뢰 기반으로 잘 풀어줌
us-east-1 리전은 상상 이상으로 큼. 최근 공개된 정보 기준 159개의 데이터센터가 있다고 함. 수백만 계정이 여기에 집중되어 있을 수도 있음. 이 현상이 AWS 장애와 연결되었을 수도 있지만, 개인적으로는 우연일 가능성이 더 높다고 생각함
이상하게 들리겠지만, 혹시 API key 보내주면 유출 리스트에 있는지 확인해볼 수 있을 것 같음