Burp Suite: Server-side vulnerabilities (Part 2) : Authentication

 

인증 취약점(Authentication vulnerabilities)

인증과 보안은 직접적으로 연결되어 있어 치명적인 영향을 끼친다. 인증 취약점은 공격자가 민감한 데이터나 기능에 접근할 수 있게 만들 수 있고, 더 많은 공격을 시도할 수 있게 attack surface를 노출한다. 인증 취약점을 찾고, 악용하는 방법뿐만 아니라
일반적인 보안 방어 메커니즘을 우회하는 법까지 배우는 것이 중요.

해당 섹션에서는
- 웹사이트에서 일반적으로 사용하는 인증 방식들
- 그 방식들에서 발생할 수 있는 취약점들
- 각 인증 방식이 가지는 고유한 구조적 한계
- 잘못 구현했을 때 생기는 전형적인 취약점들
- 강력한 인증 시스템을 만들기 위한 방법들
에 대해 배운다.

인증과 인가의 차이

인증은 user가 주장하는 사람이 맞는지 확인하는 과정, 인가는 user가 어떤 행동을 할 수 있는 권한이 있는지 확인하는 것

 

Brute-force attacks (브루트 포스 공격)

무차별 대입 공격. 시스템적으로 계속 반복해서 시도해 유효한 아이디/비밀번호를 맞추려고 하는 공격 방식으로 일반적으로 wordlist를 사용해 자동화한다. 그리고 잭 더 리퍼 같은 전용 툴을 사용하면 고속으로 더 많은 로그인 시도를 하게 되어 위험성이 커진다. 브루트 포스 공격이 항상 완전히 무작위로 ID와 비밀번호를 던져보는 방식만 있는 건 아니고 공개된 정보를 활용해 추측이 가능해지기도 한다. 이럴 경우 성공률이 더 올라감.

 

usernames은 이메일 주소 같이 패턴만 파악하면 유추하기가 쉽다. 예를 들어 이메일 포맷이 이름.성@회사이름.com인 경우.. 아니면 admin, administrator처럼 권한 높은 사용자명을 사용하는 경우가 이에 해당한다. 이런 usernames을 공개적으로 사용하는지 감사할 때 확인하면 좋다. 프로필에 사용된 이름이 username과 동일해서 profile이 hidden 된 상태여도 로그인 없이 profile에 접근이 가능할 수도 있다. 그래서 http response에 이메일 주소가 공개되어 있는지도 확인하면 좋다고. 특히 it 관련 admin 계정에 유의해야 한다. 

 

passwords의 경우 비밀번호 정책을 대부분 따르고 있다. 최소 비밀번호 자릿수, 대소문자 혼용, 하나 이상의 특수문자 사용 등 그럼에도 불구하고 user는 랜덤 문자를 조합한 비밀번호를 쓰기 보다는 기억하기 쉬운 걸로 사용을 해서 정책을 따르곤 한다. 

 

예를 들어서 secumark 인데 SecuMark*) 이런식으로 유추하기 쉽게.. 

 

정책상 사용자가 정기적으로 비밀번호를 변경해야 하는 경우, 사용자들은 종종 기존에 선호하던 비밀번호에 약간의 예측 가능한 변경만 하는 경우도 많음 Secumark1인데 Secumark6으로 바꾼다든가..  이런 예측 가능한 패턴도 공격자가 알게되면 훨씬 더 정교하게 공격을 할 수 있다. 

 

username 열거, 목록화 공격은 공격자가 웹사이트의 동작 변화를 관찰해 입력한 사용자 이름이 유효한지 확인할 수 있을 때 발생함. 일반적으로 로그인 페이지에서 이 취약점이 발생하는데, 예를 들어, 존재하는 사용자 이름을 입력했는데 비밀번호만 틀렸을 경우 비밀번호 틀렸다고 하거나.. 회원가입 페이지에서 이미 사용 중인 아이디입니다 같은 메시지도 이해 해당. 그럼 실제 존재하는 아이디인지 쉽게 확인이 가능해진다.

 

Lab 

예측 가능한 username이랑 password를 활용해서 wordlist로 brute-force 공격을 진행할 것이다. 

 

로그인 페이지에서 username과 password를 secumark로 입력해봤다. 

POST /login HTTP /2로 요청 헤더가 시작되고 있어 username과 password는 body 부분에 들어가는 것을 확인했다.

 

 

invalid username이라고 하면서 없는 아이디라고 말하는 중

 

그리고 실습에 제공된 wordlist를 활용해서 intruder로 brute-force 공격을 하면 되는데, 한번도 해본적이 없어서 해당 실습 페이지 내에 있는 solution의 힘을 빌렸다.

 

Proxy > HTTP history로 가서 아까 요청했던 부분을 찾는다. (POST /login) 그리고 username 파라미터 값을 선택해 Intruder로 전송하면 된다. 
Intruder에서는 username=§invalid-username§처럼 §기호로 둘러싸인 부분이 자동으로 페이로드 위치로 설정된다. 이때 비밀번호는 아무 값이나 고정된 값으로 일단 둔다.

 

intruder로 가면 다음과 같이 떠있을 것이다. 근데 username 부분만 저 § 기호를 넣은 상태여야 하기 때문에 나머지는 clear 해줬다.

 

attack type은 sniper로 설정

payload sets는 아래와 같이 simple list로 하면 된다.

 

 

실습에 나와있던 username 정보를 paste 해주고

 

 

공격을 누르면 다음과 같은 결과가 나온다. Length 필드가 모두 3248로 동일한데, app1이라는 username 하나만 3250으로 미세하게 다르다.

 

 

더블클릭을하면 해당 reqeust와 response를 더 자세하게 볼 수 있다! 

다른  payload는 모두 invalid username이라는 결과가 나오는데, app1만 incorrect password라고 결과가 나온다. app1은 실제 존재하는 id라는 것을 알았으니

 

다음과 같이 username=app1으로 설정하고, 이 다음에는 password 부분에 sniper attack을 진행하면 되겠다.

 

payload options에 비밀번호 wordlist를 넣어두고 공격을 하면

 

 

하나의 payload만 status가 302로 뜨는 것을 확인할 수 있다!

 

302 Found는 HTTP의 상태 코드인데, Temporary redirection을 뜻한다. 말 그대로 요청한 페이지가 임시로 다른 위치로 이동한다는 건데, 로그인 성공 or 실패 후 이동한다는 뜻이다. 뭐 /dashboard, /home 이런식으로 리디렉션 됨.

 

 

그래서 302 status 코드도 그렇고 Set-Cookie: session 설정도 되어있다. 

 

로그인하니까 성공

 

Bypassing two-factor authentication

2FA 인증은 우회하기 좋은 조건이다. 처음에 유저가 로그인할 때 비밀번호를 입력하고, 다른 페이지에서 Verification code를 입력하는 경우 verification code 입력 전에 이미 logged in 상태로 바껴있을 것이다. 2번째 단계로 가는 건 별로 중요하지 않고, 첫번째 비밀번호를 입력했을 때 성공했는지 아닌지를 더 신경쓴다는 뜻.

 

그래서 이번 실습에서는 그 우회법을 적용해볼 것이다. username이랑 password는 가지고 있는데, 2FA 인증까지는 접근할 수 없는 상황. 

 

Your credentials: wiener:peter
Victim's credentials carlos:montoya

 

먼저 내 계정으로 로그인을 하면, 2FA 인증을 하라고 내 메일로 인증코드를 보낸다.

 

들어가서 보면 다음과 같이 메일이 와있을것이다.

이때 URL은 ~/my-account?id=wiener  이다.

 

로그아웃하고 이번엔 carlos 계정으로 접근, 이때 url은 /login2이다.

 

 

2차 인증 단계에서 링크만 바꿔줬더니 myaccount에 접근이 가능해졌다.