Offensive Security Series - Kerberos

오펜시브 시리즈

해당 오펜시브 시큐리티 시리즈는 말그대로 내가 Offensive Security를 공부하며 Obsidian에 정리한 자료들을

 

rawdata로 업로드하는 시리즈이다. 이걸 올리는 이유는 가장 큰 목적은 자료 공유, 두번째 목적은 블로그 활성화이다.

 

사실 내가 블로그를 막 신경쓰진 않는데 그래도 만들어둔 이상 꾸준히 글은 올려야할 것 같다는 압박감이 있어서 ...

무언의 압박감

 

공부하면서 자료 정리하고 올릴 예정이다. 물론 그때 그때 정리한 자료를 바로 올리는 건 아니고 어느정도 정리가 잘 됐다?

 

싶은 것들 위주로 올릴 것이다.(내 ㅈ대로 올리겠다는 뜻)

 

근 1년간 CTF가 재미없어서 잘 안뛰기도 했고, 사실 해킹 공부 자체가 별로 재미가 없었다. 그래서 블로그 쓸 게 별로 없었다.

 

그러다가 최근에 레드팀 관련 공부하는 게 좀 재미있어져서 다시 공부 좀 하고 있다.

 

원래도 1년전부터 주말마다 조금씩 시간 투자하면서 레드팀 공부는 꾸준히? 해왔는데 ...

 

사실 꾸준히라는 워딩이 맞나 싶다. 주말에만 했었고, 주말에도 약속 잡히거나 일정 있으면 안했기 때문이다.

 

그래도 최근엔 다시 해킹 공부 재밌기도 하고, OSCP라는 목표가 생긴만큼 좀 열심히 해보지 않을까 싶다.

 

해당 글은 마크다운으로 작성되기 때문에, 노션이나 옵시디언에 복붙해서 보는 것을 추천한다.

 

오타, 잘못된 정보 있으면 디스코드 one3147로 연락 바랍니다.

 

자료 정리

## 이론 및 개념
### Kerberos
- 네트워크 인증 방식 중 하나
- 보안이 보장되지 않은 네트워크 환경에서 요청을 보내는 유저와 서버가 서로의 신뢰성을 확보하기 위함
- 이는 사용자의 신원을 보증해주는 역할만 하지, 사용자가 접근 가능한 서비스나 리소스를 검증하지 않음
- 리소스에 대한 사용자의 액세스를 검증하는 것은 각 서비스의 책임
- Windows2000 이상부터 Kerberos를 기본 인증 방법으로 사용
- 클라이언트를 윈도우 도메인에 가입시킬 경우, 해당 클라이언트에서 윈도우 도메인과 해당 도메인과 신뢰
관계가 있는 모든 도메인의 서비스에 대한 인증을 Kerberos를 거침
- 반대로 클라이언트나 서버 둘중에 하나라도 신뢰관계에 있지 않다면 NTLM을 인증에 사용
- NTLM : NT LAN Manager, challenge-response 기반 인증 프로토콜
- 비밀번호를 단 한 번도 네트워크에 안 흘리면서 세션키 체인을 굴리는 프로토콜

### 용어
KDC : 서버와 사용자에 대한 신뢰관계 정보를 관리하는 중앙 DB
AS : 인증 서버, 사용자로부터 인증을 수락하는 서버
TGS : 티켓 발급 서버, 각 서버를 이용하기 위한 티켓을 발급하는 서버
Principal : KDC가 인증하는 사용자 및 서버
Realm : 동일한 KDC 아래의 시스템들을 논리적 그룹으로 정의
TGT : 커버로스의 신분증, 다음과 같은 정보를 포함함
- Client ID
- Client IP
- 유효기간
- TGS session key
### 구조
Domain Controller
 └── KDC 서비스
       ├── AS (Authentication Service)
       └── TGS (Ticket Granting Service)
- DC 한 대가 Kerberos 인증 전체를 담당
Other Servers
- 서비스 서버는 파일서버, 웹서버, MSSQL, Exchange, 내부 API, SMB, LDAP, WinRM 등 Kerberos로 보호되는 모든 자원

💾 : 전송되는 데이터 정보(Flow를 그려내기 위한 정리)
### 인증 흐름
**Client Authentication**
1. 로그인시도 -> id를 AS(인증 서버)로 전송 (pw 전송X)
- 💾 클라이언트 -> KDC 서비스 내 AS : 유저 ID 전송

2. AS는 DB에서 유저 id 확인 후 다음과 같은 데이터 반환
a. DB에서 찾은 유저의 pw 기반(pw에서 파생된 사용자 long-term key)으로 암호화한 TGS 세션키
-> 여기서 TGS 세션 키는 TGS와 대화할 때 쓰는 키
-> 클라이언트와 TGS 간 이후 통신을 보호하기 위한 대칭키
-> 이때 long-term-key는 패스워드에 (string2key / hash / KDF)를 적용한 것
b. 클라이언트 id, ip, 티켓유효기간, TGS 세션 키를 TGS비밀키로 암호화한 티켓 발급용 티켓 TGT
-> 암호화된 TGS 세션키, TGT(Ticket Granting Ticket)을 리턴 받음
-> TGT는 AS가 발급하고 TGS만 열어볼 수 있음
- 💾 KDC 서비스 내 AS -> 클라이언트 : 암호화 된 TGS 세션키, TGT 전송

여기서 클라이언트가 데이터를 받을 때 사용자가 입력한 pw가 틀렸을 경우 메세지 복호화 불가능
-> AS가 TGS 세션 키를 유저 PW(이건 DB에서 꺼내온 값)에서 파생된 키로 암호화해서 전달
-> 사용자가 입력한 PW가 틀리면 복호화 불가
-> 메세지는 AS서버로부터 응답의 암호화 파트

**Client Service Authorization**
3. 클라이언트가 아래 정보를 TGS로 전달
a. 클라이언트 id, TimeStamp를 TGS 세션키로 암호화한 것
b. TGT
- 💾 클라이언트 -> KDC 서비스 내 TGS : TGS 세션키 암호화(클라이언트 ID, Timestamp를 포함), TGT(클라이언트 ID, IP, 유효기간, TGS Session Key를 포함)

4. TGS는 TGT와 인증정보를 복호화하여 Client id가 일치할 경우 다음 메세지 반환
a. TGS 세션 키로 암호화한 서비스 서버 세션키
b. 서비스서버 비밀키로 암호화한 티켓
-> 이 단계에서 클라이언트는 서비스 서버에 자신을 인증할 수 있는 충분한 정보를 가짐
- 💾 KDC 서비스 내 TGS -> 클라이언트 : TGS 세션키 암호화(서비스 서버 세션키), 서비스서버 비밀키로 암호화(TGT)

**Client Service Request**
5. 클라이언트는 아래 정보를 서비스 서버로 전달
a. 클라이언트 id, Timestamp를 서비스 서버 세션키로 암호화
b. 서비스 서버 비밀키로 암호화된 서비스 서버 티켓(클라이언트 ID, IP, 유효기간, 서비스 서버 세션키를 포함)
- 💾 클라이언트 -> 서비스 서버 : 서비스 서버 세션키로 암호화(클라이언트 ID, Timestamp), 서비스 서버 비밀키로 암호화(서비스 서버 티켓)

6. 서비스 서버는 서비스 서버 티켓과 인증정보를 복호화하여 Client ID가 일치할 경우 다음 메세지 반환
a. Timestamp를 서비스 서버 세션키로 암호화해서 반환
- 💾 서비스 서버 -> 클라이언트 : 서비스 서버 세션키 암호화(TimeStmap)
7. 클라이언트는 전달 받은 timestamp와 자신이 인증정보에 담았던 timestamp 값을 확인하여 일치하는 경우 서비스 서버에 서비스를 요청할 수 있게 됨
8. 서버는 클라이언트에게 서비스를 제공 (인증 성공!)

### 옵션에 따른 인증 flow의 변화
```
AS  → TGT 발급
TGS → Service Ticket 발급
Service → 실제 접근
```
- 해당 skeleton은 변하지 않음
#### Pre-Authentication
- ON인 경우
- Client → AS: timestamp encrypted with password 먼저 전송
- AS : 맞으면 TGT 발급
- OFF인 경우
- 이전에 기술한 바와 같이 인증 절차가 흘러감
- Client → AS: userId 전송
- 암호화된 TGS session key 바로 반환
#### TODO : Mutual Authentication, Ticket Lifetime, Cross-Realm Trust ...

### 주의 사항
- 기본적으로 서버가 한대라 장애 발생시 로그인 불가
- 요청시간에 대한 요구가 엄격하여 요청을 주고 받는 서비스들 간의 시간 동기화 필수

### Port 정보
- TCP 88 : 커버로스 인증 프로토콜, KDC 서비스에 사용

### 위협 시나리오
- Client Authentication 단계
- 클라이언트에서 암호화 된 TGS 세션키, TGT를 받아올 때, 패스워드가 약할 경우 TGS 세션키 복호화에 패스워드 무차별 대입을 통해 패스워드 크랙 가능
- TGS 세션키는 PW에서 파생된 long-term key로 암호화 되기 때문


## 공격 
### 도메인 정보 파악
- 뭔가 case by case로 나오는 경우도 안나오는 경우도 있는 듯함
- nmap, smb, 등등의 다양한 프로토콜에서 Osint하는 느낌으로 찾아야하는 듯함
- 에러에서 노출된 네트워크 배너를 찾거나 auth flow 과정에서 packet 내에 노출되는 banner를 탐색
- HTB 특정 머신에선 `nxc smb <ip>` 로 발견

### Pre-Authentication OFF 계정 리스팅
- AS-REP 요청을 이용한 공격
- Kerberos 인증 흐름의 맨 첫 단계 패킷을 이용한 정찰
- Preauth OFF의 경우
- PreAuth 필요 없음 → AS-REP 바로 반환
- Preauth ON의 경우
- timestamp 보내라” 하고 요구만 하기 때문에 패스워드 검증 X
- 계정 잠기지 않음
- 방화벽 등에 의해 이상징후 탐지 가능성은 있을 듯 함
```
impacket-GetNPUsers tombwatcher.htb/ -dc-ip <ip> -usersfile /usr/share/seclists/Usernames/xato-net-10-million-usernames-dup.txt
```