현재 글로벌 서비스를 통해서 웹과 앱을 만들고 있습니다.
글로벌 서비스는 국내 서비스보다 개발 기획과 설계 단계에서 많은 요소를 추가 고려해야 합니다.
예시로는 ‘글로벌 언어 제공’, ‘글로벌 결제 기능 제공’, ‘글로벌 계정 인증’ 등이 있습니다.
이번에는 글로벌 서비스가 취약한 계정시스템에 대한 해커의 어뷰징 행위를 어떻게 해결하고 있는 지 정리해보려고 합니다.
** 물론! 회사와 서비스에 관련된 민감한 정보는 제외하고 작성하도록 하였습니다.
설명할 “글로벌 서비스에서 계정시스템을 지켜온 과정”은 간략하게 다음과 같습니다.
다음 3가지의 구분된 과정으로 설명합니다.
1. Business(B) : 비즈니스에 필요한 서비스 구현
2. Attack(A) : 구현된 서비스에 대한 해커의 공격
3. Reinforce(R) : 해커 공격을 방어하고 강화
4. Monitoring(M) : 서비스의 상태 모니터링
현재까지 계정시스템을 방어해온 과정은 간략하게 다음과 같습니다.
B ”이메일 계정 API MVP 개발” → A “이메일 회원 가입 API DDoS 공격”
→ R “이메일 인증 프로세스 도입” → M “이메일 인증 프로세스 도입 이후, 어뷰징 사용자 지표 확인”
→ A “이메일 가입 여부 확인 API Brute Force 공격” → A “이메일 로그인 API Brute Force 공격”
→ R “‘AWS WAF’-’Web ACLs’-’Rule’ 적용” → M “계정 탈취 공격 방어 후, 지표 확인”
→ B “사용자 휴대폰 SMS 인증 도입” → A “사용자 휴대폰 SMS 인증 API Brute Force 공격”
→ R “Application IP Block 정책 적용” → R “Application SMS 번호인증 횟수 제한 정책 적용”
→ R “Application 이메일 유효성 확인 정책 적용” → M “‘휴대폰 SMS 인증’, ‘이메일 회원가입’ 어뷰징 확인”
여기서 부터는 어떻게 계정시스템이 지켜져왔는지 자세하게 설명하겠습니다.
1. Business: 이메일 계정 API MVP 개발
•
MVP Open API 개발 배포
◦
“이메일 회원 가입”
▪
정규식을 통한 이메일 형식 Validation
▪
패스워드 조합 복잡도를 적용하고 형식 Validation
▪
이미 존재하는 이메일은 발생
◦
“이메일 가입 여부 확인”
▪
정규식을 통한 이메일 형식 Validation
▪
이미 존재하는 이메일은 발생
2. Attack: 이메일 회원가입 API DDoS 공격
“이메일 회원가입” API 배포 이후, 얼마 지나지 않아 다음과 같은 어뷰징 스크립트 DDoS 공격 들어왔습니다.
DDoS의 영향
DDoS 공격으로 신뢰할 수 없는 회원가입이 이루어졌고, 실제 사용자 계정과 관련없는 더미 데이터들이 DB에 쌓이게 되었습니다.
동시에 계정을 관리하는 인증서버는 트래픽을 견디지 못하였습니다.
Auto Scaling을 적용하였지만, Scale-out 속도와 DDoS 공격속도는 일정하지 않아서 한동안은 로그인이 지연되거나 실패하는 장애로 이어졌습니다.
최고점에는 평소 트래픽의 8배의 RPM(Requests Per Minute)을 발생시켰습니다.
물론 Scale-out이 진행된 후에는 장애로 이어지지 않았습니다.
Scale-out 동안 장애를 발생시키지 않기 위해서 새롭게 만들어진 Instance의 Health Check 주기를 최대한 줄여서 트래픽을 처리할 수 있게 하였습니다.
이 문제를 사용자의 최소 인증을 통해서 해결해야한다고 생각했고, 비즈니스팀과 공감하여 “이메일 인증 프로세스 도입”을 추진하였습니다.
3. Reinforce: 이메일 인증 프로세스 도입
•
이메일 인증 프로세스
1.
회원 가입 요청
2.
인증 이메일 발송
a.
Activation key 발급 후, 인증 이메일 전송
3.
이메일 인증
a.
이메일에 전달된 Activation key로 사용자 활성화 API 호출
4.
사용자 계정 활성화
a.
비활성화 계정과 이메일이 인증된 활성화 계정 구분
4. Monitoring: 이메일 인증 프로세스 도입 이후, 어뷰징 사용자 지표 확인
•
사용자 이메일 인증으로 얻은 효과
◦
인증된 사용자의 데이터를 쉽게 필터링
◦
이메일 인증이 사전에 차단하기에 서비스 사용이 안되는 관계로 해커의 API DDoS 공격 중단
◦
인증 되지 않은 사용자에게 비활성화 권한을 부여하므로써 Open API 이외에는 요청 차단
5. Attack: 이메일 가입 여부 확인 API Brute Force 공격
•
사전에 다른 서비스에서 해킹된 이메일 리스트를 구매하여, 이메일 가입 여부 확인 API Brute Force 공격
◦
존재하지 않는 이메일로 공격할거라고 생각한 부분이 실수
◦
DDoS 공격이 들어올거라는 착각하였고, 해커는 RPS를 조절하여 모니터링에 보이지 않는 요청
◦
이미 존재하는 이메일로 우리 서비스에 가입되었는지 확인하고 리스트를 확보할 목적으로 공격
6. Attack: 이메일 로그인 API Brute Force 공격
•
“이메일 가입 여부 확인 API Brute Force 공격”에서 확보한 이메일 리스트와 외부에서 해킹을 통해 얻은 이메일, 패스워드 데이터셋을 대입하여 로그인 시도
•
이 과정에서 성공된 로그인 계정 리스트를 확보할 목적으로 공격
7. Reinforce: ‘AWS WAF’-’Web ACLs’-’Rule’ 적용
‘AWS WAF’는 ‘Web ACLs’라는 단위로 Priority 순서대로 ‘Rule’ 을 적용합니다.
개념적인 부분은 네트워크 ACLs와 동일합니다.
구성한 Rule 특징
- 적용된 룰은 ACLs에서와 같이 우선순위대로 상위 룰에 만족하면 해당 Action을 바로 적용하는 방식으로 구성
- 무조건 허용해야하는 “White List”를 상위에 배치, 부분적으로 차단해야하는 “Black List”를 하위에 배치
- 일정 횟수 이상 공격자의 Request를 차단하지는 않고, 로그인 위장 실패 응답으로 공격 혼란을 줌
WAF는 기본적으로 L3 ~ L7 까지 모든 트래픽을 제어할 수 있는 권한을 가지고 있습니다.
8. Monitoring: 계정 탈취 공격 방어 후, 지표 확인
계정 탈취 ATO(’A’ccount ‘T’ake’O’ver Attack)은 한 달이상 꾸준히 들어왔습니다.
꾸준히 “이메일 가입 여부 확인 API”, “이메일 로그인 API” 공격이 들어왔고,
Spike 패턴이 조금 보이긴 하지만, 단기간의 공격으로 생각하였습니다.
여기서 핵심은 Rule 적용시, 차단된 요청에 대해서 로그인 위장 실패 응답으로 요청 자체는 차단되지는 않지만 로그인 결과물이 데이터 노이즈가 발생하기에 이후에 ATO를 멈추었습니다.
9. Business: 사용자 휴대폰 SMS 인증 도입
이후에 글로벌 서비스의 특성 때문에 해킹이 아니더라도 어뷰징 행위가 증가했습니다.
어뷰징의 종류로는 비실명이다 보니 결제 과정에서 다른 사람 명의를 도용하여 결제를 시도하는 것과 같은 행위로 법적 분쟁 요소가 발생하였습니다.
결국에는 비실명 계정이 발생시킬 수 있는 Fraud 어뷰징 행위입니다.
그래서 솔루션으로 “사용자 휴대폰 SMS 인증”을 도입하게 되었습니다.
대신에 기존에 있던 이메일 인증을 없애므로써 기존에 회원가입 에서 단계가 늘어나지는 않습니다.
사용성은 기존과 크게 다르지 않지만 실명성을 얻는 방식의 변화가 있었습니다.
10. Attack: 사용자 휴대폰 SMS 인증 API Brute Force 공격
“이메일 가입여부 확인” 후, “이메일 회원가입” 스크립트 공격이 다시 시작되었습니다.
”휴대폰 SMS 인증”이 도입되었기 때문에 이메일 회원가입만으로는 서비스에 장애는 없었습니다.
하지만, 계정 데이터가 어뷰징으로 노이징되었습니다.
서비스에 문제는 없었지만, 문제는 다른 곳에 있었습니다.
이메일이 생성되고 난 후, “휴대폰 SMS 인증”이 되기 때문에 SMS 인증 요청이 가능한 것이었습니다.
SMS 인증 요청이 가능하게 되면, 많은 요청이 발생하게되고 SMS 전송 비용이 높아졌습니다.
기존 하루에 몇만원에 불과하던 SMS 전송 비용이 4시간만에 100만원씩 소진되었습니다.
애초에 해커의 공격은 100% 막을 수 없기에 해킹이 어렵게 만드는 정책을 적용해나가는 것으로 전략을 정의했습니다.
11. Reinforce: Application IP Block 정책 적용
•
“Application IP Block 정책” 상세 내용
◦
제한 시간 이내에 일정 횟수 이상의 동일한 IP 회원가입 방지 (WAF, Application 모두 적용)
◦
기본적으로 WAF가 적용되어있지만, “IP 변경”, “이메일 무차별 계정 생성”, “존재하는 휴대폰 데이터”를 확보하여 공격함
12. Reinforce: Application SMS 번호인증 횟수 제한 정책 적용
•
“Application SMS 번호인증 횟수 제한 정책” 상세 내용
◦
제한 시간 이내에 일정 횟수 이상의 휴대폰 SMS 인증 방지
◦
번호당 인증 요청 제약을 주었고, 기본적으로 프론트에서도 제한
13. Reinforce: Application 이메일 유효성 확인 정책 적용
•
“Application 이메일 존재 여부 확인 정책” 상세 내용
◦
이메일 검증 Thirdparty를 활용하여, 이메일 유효성 확인 로직 추가
14. Monitoring: ‘휴대폰 SMS 인증’, ‘이메일 회원가입’ 어뷰징 확인
WAF, Application, Thirdparty 를 활용하여 발생하고 있는 모든 경우에 대해서 어뷰징을 막고 있습니다.
어뷰징 행위에 대해서 미리 예측하고 막으면 좋겠지만, 모든 경우를 대처하기에는 무리가 있습니다.
현재는 필요한 시점에 기존에 비즈니스를 최대한 보완할 수 있는 방식으로 어뷰징에 대한 방어가 충분하다고 생각하고 있습니다.
물론 치명적인 어뷰징 행위는 사전에 최대한 막는 것이 중요합니다.
치명적일 수 있는 부분은 Application Layer에서 Spring Security와 같은 솔루션을 활용하면 된다고 생각합니다.
이후에도 발생할 수 있는 어뷰징 행위에 대처하기 위해서 아래와 같은 솔루션을 고려하고 있습니다.
아래 솔루션의 공통점과 최근 트랜드는 사용자에게 ‘그림을 찾아라 같은’ 불편함을 주지 않으면서 행동을 분석하여 Score로 Embedding하여 어뷰징을 탐지하는 방식으로 진화하고 있습니다.
추가 도입을 고려하고 있는 솔루션
reCAPTCHA v3
•
도입 목적
◦
UI에서 행동 패턴을 분석하여 어뷰징 사용자 추출 솔루션 반영
•
도입 효과
◦
Score based, user’s analysis
◦
Validation Token
Email Validation & Verification
•
도입 목적
◦
이메일의 유효성을 검사하기 위한 다양한 솔루션 반영
•
도입 효과
◦
Email Validation
◦
Email Activity Data
◦
Email Score
◦
Blacklist Monitor
