우선 개념적으로, Authentication vulnerabilities 는 이해하기는 쉽습니다. 그러나 authentication 과 security 의 명확한 관계 때문에 이것은 매우 중요합니다.
Authentication vulnerabilities 는 공격자가 민감한 데이터나 기능에 접근할수 있도록 합니다. 더 나아가 추가적인 공격도 가능하구요. 그러므로 인증 취약점을 식별하고 알아내며 , 흔한 보호조치를 우회하는 방법을 학습해야 합니다.
이번에 제가 얘기드릴것은:
- 가장 주로 웹사이트에서 쓰이는 인증 메커니즘
- 이러한 메커니즘의 잠재적 취약점
- 다른 인증 메커니즘의 내재된 취약점
- 그것들의 부적절한 수행으로 발생되는 전형적인 취약점
- 자체인증 메커니즘을 가능한 견고하게 만드는법.
-What is the difference between authentication and authorization?
사전적 정의로 보자면
인증(Authentication) : 본인이 누구인지 확인하는것
인가(Authorization) : 특정 리소스에 권한이 있는지 확인 하는것.
예를들자면 놀이동산에는 표를 산 일반인,관리자 이 두가지의 사람들만 출입할 수 있는데 이것을 판단하는것(인증)
관리자 휴게실은 일반인은 못들어 오고 관리자만 들어올 수 있으니,관리자 인지 확인하는 것 (인가)
-Brute-force attacks(무차별 대입 공격)
A brute force 공격은 주로 공격자들이 유효한 유저의 정보를 알아낼때 시스템을 사용하여 시도합니다.
이 공격은 주로 "이거일것 같다" 라고 추측 되어지는 유저 이름과 비밀번호가 들어있는 Wordlists 가 사용됩니다.
자동화 툴을 사용하여 매우 빠른속도로 여러개의 숫자를 무차별로 대입하여 맞을때까지 시도하는 공격입니다.
(그렇다고 아무거나 막 넣지는 않고, 그 유저랑 관련된 정보들을 추합하여 논리적으로 여러개의 비밀번호를 추측해본 후 wordlist 에 작성하고나서 진행하게 됩니다. 무지성으로 막 대입하는 것은 절대 아님!)
<Brute-forcing usernames>
그러면 유저 네임은 어떻게 추측하냐? 라고 하신다면 사실 생각보다 꽤 간단할 수 있습니다. 주로 사람들의 이메일 주소에서 보이는 특정한 패턴이 있는데 그것으로 알 수 있는 경우가 많죠. 또한 어떤 사이트는 관리자의 유저 네임을 admin 혹은 administrator 이라고 해두는 경우도 있습니다. (생각해보니 아는 개발자 분의 사이트 관리자 ID 가 admin 이네요...)
<Brute-forcing passwords>
패스워드는 얼마나 견고하냐에 따라 다르지만 유저네임과 비슷하게 알아낼 수 있습니다.
많은 웹사이트가 복잡한 패스워드의 조건을 걸고 있는데, 일반적으로 :
- 숫자가 들어가야함
- 대문자 소문자의 조합
- 적어도 하나의 특수문자를 사용해야함
이러한 조건들을 달고 있습니다.
패스워드가 복잡해지는 만큼 분명히 뚫기는 어렵습니다 , 하지만 저희는 사람입니다. 사람은 아무리 복잡해도 자기와 연관된 기억하기 쉬운 패스워드를 만들고 그 패스워드에서 크게 벗어나지 않는선에서 돌려쓰기 마련입니다.
예를들어 mypassword 가 안된다면 , Mypassword1! 이라던가 Myp4$$w0rd 라는 식으로 크게 벗어나질 않습니다.
심지어 비밀번호를 잊어먹어서 바꿔야된다면 Mypassword1! -> Mypassword1? 라는 식으로 특수문자만 바꾸는 경우가 많죠.
(참고로 사람들은 못뚫을 정도의 복잡한 비밀번호 라면 주로 아날로그 식으로 어딘가 적어놓는다는 경향이 있습니다. 그래서 그러한 사회공학기법을 이용하여 비밀번호를 알아내면 이후 그 사람과 관련된 비밀번호의 형식을 알게됐으니 wordlist 를 작성할 수 있습니다. )
이러한 논리를 가지고 무차별 대입공격을 진행한다면 , 이것이 무식한 방법이 아닌 꽤 논리적인 방법이라고 생각이 됩니다.
<Username enumeration>
유저네임의 목록은 공격자들이 유효한 ID 와 그렇지 않은 ID 를 넣었을 때 웹사이트의 오류메세지 차이를 이용하여 유효한 ID 를 찾을때 사용합니다. 그러한 오류메세지에는 세 종류가 있습니다.
1.Status codes: 만약 유효한 ID가 들어갔다면 그렇지 않았을때와는 다른 상태코드가 뜰것입니다.
2.Error messages: 가끔 ID부터 틀리면 "ID 혹은 비밀번호가 틀립니다" 에서 ID 만 맞으면 "비밀번호가 틀립니다" 라는 식 의 메세지를 띄우는 사이트가 있습니다. 그러면 이 메세지의 차이를 이용하여 유효한 ID 를 무차별 대입으로 먼저 알아 낼 수 있게 됩니다. 그 이후에 패스워드를 알아내는 것이죠. 단계별 진행이라는 겁니다.
3.Response times: 주로 요청을 처리하는 시간은 비슷합니다. 그러나 응답내용이 달라지면 아주 미세한 응답시간 차이가 발생하게 되는데, 이것은 유저네임을 추측할 수 있는 지표가 됩니다.
예를들어 웹사이트가 ID 가 유효하기만 하면 ID는 제대로 체크 안하고,패스워드만 제대로 체크하는 경우가 있습니다.
즉 ID 가 유효하지 않으면 패스워드를 확인하지도 않고 틀렷다는 메세지를 띄울것 이며 이로인해 미세한 응답시간 차이가 발생하게 됩니다.
이를 이용하여 ID 를 찾기위해 무차별 대입공격을 할때 패스워드에 엄~~~~~~~청! 긴 문자열을 넣게되면 이것을 처리하는 시간이 지연이 되게 되고 ID 가 유효할때와 아닐때의 비밀번호를 처리하는 시간의 차이가 발생하여 , 무차별 대입으로 넣은 ID 가 유효한지 아닌지를 알 수 있게됩니다.
[추가] Response contents length : 만약 메세지의 응답이 다르다면 상태코드도 다르겠지만 , Contents 의 내용 length 또한 다를것입니다. 이 차이점을 이용하여 뭔가 발생하였구나 라고 추측할 수도 있습니다!
-Bypassing two-factor authentication
만약 로그인을 해서 들어갔는데 2차인증 코드를 작성하라 하면 어떻게 해야하나?
때때로 로그인을 한 후 2차인증 화면이 떳을땐 이미 우리는 사실상 로그인이 된 상태에 머물게 됩니다.
이 점을 이용하여 2차코드 인증화면에서 home 으로 다시 가게되면 로그인 상태에 머물게 되는 경우가 있습니다.
그러니 2차인증 화면에서 홈으로 되돌아 가보는것은 테스팅해볼 가치가 있습니다.
<실습>
실습 사이트의 유저네임 과 패스워드의 wordlist 를 받았다.
 |
 |
| ID list | Password list |
제일 첫번째 ID 와 비밀번호를 넣어봣더니 Invalid username 이라는 문구가 떳다.
내가 이 사이트에서 check 하고 싶은것이 두가지 있다.
1.유효한 ID일땐 다른 문구가 뜰까?[위에서 말한 2번 과 추가 취약점]
2.ID 가 유효할때 상태코드가 달라질까?
이제 무차별 대입공격을 진행하여 보자
Burp suite 프로그램 -> proxy -> 방금보낸 패킷을 Intruder로 보낸다 ->carlos 부분을 바꿀꺼라고 $ 표시를 해준다 -> simple list 를 선택후 wordlist 의 ID 내용을 붙여넣기 한다 -> 공격시작!
-> 1. ID 가 applications 일때 length 가 혼자 다른것으로 보아 무언가가 일어났다는것을 알수있다.
Response 를 보니 아까 떳던 문구가 Incorrect password 라는 메세지로 바뀌었다는 것을 알수있다. 그러므로 내가 알아보고 싶던 1번 내용은 확인 됐었다... 그러면 status code 는?
2. 아쉽게도 똑같은 200 이라는 응답을 보내왔다. 그러니깐 satus code 만으로는 유효한 ID 를 찾아낼수 없던것이다.
자 그러면 일단 ID가 applications 라는 유저가 있다는 것은 알겠다.
그러면 이제 패스워드를 무차별 대입 공격 해보자.
똑같은 방식으로 진행하여 보겠습니다.
이번에는 Status code 와 length 둘다 다르다는것을 알수 있다.
그러면 비밀번호가 12345678일때 혼자만 응답이 다르니 이것으로 로그인 해보겠습니다.
로그인이 되었고 LAB solved 가 상태창에 뜨게되었다 . 이로써 무차별 대입공격 실습을 마치도록 하겠습니다.
'웹해킹' 카테고리의 다른 글
| SQL Injection(SQLi) (0) | 2024.05.27 |
|---|---|
| File upload vulnerabilities (0) | 2024.01.30 |
| SSRF(Server-side request forgery) (0) | 2024.01.29 |
| Access control (2) | 2024.01.25 |
| Path traversal (1) | 2024.01.24 |