웹해킹 #7 취약한 인증 공격

*정의

: 사용자 계정 정보를 확인하거나 세션 토큰과 같은 인증에 사용되는 토큰 정보를 입수하여 인증 과정 우회

 

* 발생 원인

: 인증 과정이 제대로 보호되어 있지 않아서 공격자가 인증 과정을 우회할 수 있는 경우 발생

 

- 취약한 인증 리스크 사례

① 프로그램 설치 시 기본 관리자 계정이 admin/admin과 같이 쉽게 추측할 수 있는 값으로 설정된 경우

② 패스워드 또는 패스워드를 알아내기 위한 힌트를 다른 사용자가 초기화 및 복구할 수 있는 경우

③ 세션 관리의 문제로 인해 사용자의 세션 ID가 노출되어 공격자가 세션 하이재킹 공격이 가능한 경우

④ 세션ID를 쉽게 추측할 수 있는 경우

⑤ 세션에 대한 타임아웃이 없어, 오래된 세션 ID를 사용해서 인증이 가능한 경우

 

1. 브루트 포스 공격 개요

- 특정 정보(주로 패스워드)를 알아내기 위한 공격

- 패스워드 크래킹이나 웹 애플리케이션을 대상으로 로그인에 필요한 사용자 패스워드를 알아내고자 할 때 사용

- 로그인을 여러 번 실패하더라도 다음 로그인 시도에 아무런 제한을 하지 않는 경우에 사용됨

- 공격 방법

① 일련의 문자들을 하나씩 입력 -> 무작위 브루트 포스

② 사람들이 자주 쓰는 패스워드를 이용하여 로그인 시도 -> 딕셔너리 공격

 

2. 브루트 포스 공격 실습

- 목표 : 버프 스위트의 인트루더 기능 이용하여 딕셔너리 공격 수행 -> 패스워드 알아내기

① 취약점 확인

* 프록시->인터셉트 기능 끄고 진행

② admin을 id로 아무 내용의 패스워드 입력 후 프록시 -> HTTP history 탭에서 방금 입력한 요청 (/deva/vulnerabilities/brute/로 시작하는 URL) 찾는다

③ 해당 요청을 ‘Send to intruder’을 통해 인트루더로 보낸다.

④ Intruder - Poisitions 탭

- 해당 요청의 내용에서 페이로드가 입력될 영역(연두색)이 자동으로 표시됨
- 패스워드 파라미터의 값만 변경하기 위해, ‘Clear §’ 후 password 파라미터의 값 부분에 ‘Add §’ 를 적용

⑤ Payloads 탭으로 이동

- Simple list : 페이로드 타입을 지정하면 Payload Options 리스트에 등록된 문자열을 하나씩 사용하여 요청을 전송함
- 칼리 리눅스의 /usr/share/john/password.lst : 1990년대 중반에 많이 사용된패스워드 + 2006년부터 2010년까지 웹사이트에서 많이 쓰인 패스워드
- gedit /usr/share/john/password.lst로 내용 확인 가능

- Load를 통해 password.lst 파일을 선택한 후 리스트에 추가. 그 후 #!로 된 주석 부분은 제거한 다음 Start Attack

⑥ 결과 확인

- 응답 길이가 5335인 결과 중에 5394인 결과가 존재하고, 다른 응답 페이지가 응답될 것이라 추측하여 패스워드로 짐작

 

3. 브루트 포스 공격 대응

- 짧은 시간 내에 일정 횟수 이상 로그인 시도에 실패하면, 로그인을 하지 못하게 막는 방법으로 대응 가능

  → 락킹(locking)
- 캡차(CAPTCHA) 이용 : 자동화된 프로그램은 알아내기 불가능한 흘려쓴 글자나 그림 문자를 로그인 시도 시 입력하게 함

 

4. 세션 ID 노출 사례 및 보호 대책

- 세션 하이재킹 : 세션 ID가 노출되어 공격자가 그 세션 ID를 이용하여 인증 과정을 우회하여 다른 사용자가 로그인한 것처럼 웹사이트에 접속
- 세션 ID는 일반적으로 쿠키를 통해 전달되지만, 설정 오류나 구현상의 이유 등으로 URL을 통해 전달되는 경우 존재

  → 세션 ID가 유출될 가능성이 높아짐
- 웹 서버에서 웹 요청을 전달받으면 요청 URI를 로그 파일에 기록하는데, 요청이 인터넷 상의 어떤 경로(라우터, 프록시 서버 등)로 전달될지 알 수 없어, 이러한 중계 장치들도 요청 URI를 로그로 남기게 됨

 → 공격자가 이 파일에 접근 시 노출된 세션 ID 입수 가능

- bwapp 사이트에서 ‘Session Management – Session ID in URL’ 문제에 접속 후 버프 스위트를 확인 시 요청 URI의 쿼리 스트링 부분에 PHPSESSID가 노출되어 전송되는 것 확인 가능

→ 웹 서버나 중계 장치에 공격자가 접근하여 관련 로그 조회 가능 시 PHPSESSID 확인하여 세션 하이재킹이 가능해짐

 

* 세션 ID 보호 기법

 

- 세션 ID는 쿠키나 폼의 히든필드를 통해 전달되도록 구현
- 세션 ID가 URI를 통해 노출되지 않아야 함
- 세션 ID는 HTTPS 암호화 채널을 통해 전달되어야 함
- 세션 ID를 쿠키로 전달할 경우에는 Secure, HttpOnly와 같은 쿠키 속성을 추가
- 세션 ID에 유효시간을 적용하여 일정 시간이 지나면 세션 ID를 파기. 상황에 따라 세션이 사용되지 않고 일정 시간이 지났을 때 파기하는 방법(idle timeout)과 생성된 후 일정 시간이 지나면 무조건 파기하는 방법(absolute timeout)을 선택 적용
- 로그아웃이 된 세션 ID는 즉시 파기되어야 함
- 웹 브라우저를 종료하면 자동으로 로그아웃 되도록 한다
- 세션 ID는 랜덤으로 생성되어야 하며 절대 추측할 수 없는 값이어야 함