일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 탐지
- sinature
- header dos
- rule
- IDS
- idps
- 재조합
- HTTP2
- signatrue
- slowloris
- Suricata
- chromium 탐지
- snort
- 시그니처
- Reassembly
- 크롬 탐지
- DDOS
- 암호화
- TLS
- stream_size
- chrome 탐지
- 오탐
- flowbits
- 수리카타
- 미탐
- stream buffer
- dsize
- isdataat
- IPS
- SSL
- Today
- Total
linefilt
Chromium 기반 브라우저 탐지 본문
GREASE(Generate Random Extensions And Sustain Extensibility)는 크롬 55버전 부터 추가된 필드이다. 이 필드를 통해서 현재 Chromium 기반의 브라우저를 탐지하는데 사용할 수 있다. GREASE의 목적은 TLS 통신에서 서버의 버그를 사전에 발견하고 프로토콜 확장에 따라 발생하는 문제를 방지하고자 하는 것이다.
SSL/TLS에서는 데이터를 교환하기 이전에 핸드쉐이킹을 통해서 버전 및 암호화에 필요한 정보를 교환한다. 클라이언트가 서버로 전송하는 ClienHello에 TLS 1.2을 명시하고 전송했을 때, TLS 1.2을 지원하는 서버라면 이에 대하여 정상적인 ServerHello를 통해서 응답을 진행한다. 만약 서버가 TLS 1.2를 지원하지 않는다면, 서버는 자신이 지원하는 범위의 버전을 명시하여 응답을 진행해야 한다. 하지만 일부 서버들은 TLS 버전 협상이 제대로 구현되지 않아 정상적으로 버전이 fallback 되지않고 연결이 종료되는 Version tolerance 문제가 발생한다.
서버로부터 연결이 종료된 클라이언트는 자신의 버전을 낮추어서 다시 협상을 맺는다. 연결이 불가능하지는 않겠지만, 새로운 연결이 완료되기 까지 (지연)시간은 지속적으로 늘어나게 된다.
하지만 지금 대부분의 브라우저는 버전을 fallback하는 것을 방지한다. 이는 MITM 공격이나 하위 버전의 SSL/TLS들의 취약성으로 문제가 야기될 수 있기 때문이다.
버전 다운그레이드가 불가능하다면, Version telerance는 발생하지 않을 것이다. 하지만 TLS 1.3과 같이 새로운 프로토콜이나 CipherSuite가 적용되었을 때, 자신이 식별할 수 없는 없는 값(필드)를 무시하지 않고 연결을 종료하는 문제는 여전히 발생할 수 있다. GREASE는 현재로써는 사용되지 않는 무작위성 필드를 포함하여 전송시키고 문제가 발생되는 것을 사전에 확인할 수 있다.
그림 1. Chrome 81의 ClientHello 메시지 | 그림 2. MS Edge 81의 ClientHello 메시지 |
위 그림은 Chrome과 MS Edge 두 브라우저가 www.naver.com 에 접속했을 때 ClientHello 메시지를 보여준다. 두 브라우저 모두 Chromium기반으로 버전을 동일하게 81로 명시되며, GREASE 필드가 있는 것을 확인할 수 있다. 반면, Mozilla Firefox나 MS IE는 GREASE 필드가 존재하지 않는다.
ciphersuites, ALPN | extensions, namegroups, signautre algorithms, version | PskKeyExchangeModes |
{0x0A,0x0A} | 0x0A0A | 0x0B |
{0x1A,0x1A} | 0x1A1A | 0x2A |
{0x2A,0x2A} | 0x2A2A | 0x49 |
{0x3A,0x3A} | 0x3A3A | 0x68 |
{0x4A,0x4A} | 0x4A4A | 0x87 |
{0x5A,0x5A} | 0x5A5A | 0xA6 |
{0x6A,0x6A} | 0x6A6A | 0xC5 |
{0x7A,0x7A} | 0x7A7A | 0xE4 |
{0x8A,0x8A} | 0x8A8A | |
{0x9A,0x9A} | 0x9A9A | |
{0xAA,0xAA} | 0xAAAA | |
{0xBA,0xBA} | 0xBABA | |
{0xCA,0xCA} | 0xCACA | |
{0xDA,0xDA} | 0xDADA | |
{0xEA,0xEA} | 0xEAEA | |
{0xFA,0xFA} | 0xFAFA |
Chromium은 현재 GREASE 필드를 사용할 때, 각 확장 필드 별로 가장 우선하여 배치하고 있다. 위 그림과 같이 Extensions 들에서도 GREASE는 Extension Length 다음에 가장 먼저 명시되며, Cipher Suites에서도 다른 Cipher Suite보다 먼저 명시된다.
GREASE 필드는 첨부된 표와 같이 여러 필드에서 사용되나, 가장 탐지를 적합하게 할 수 있는 것은 Extesions에 가장 먼저 명시되는 GREASE 필드이다. Extensions의 GREASE 필드의 앞에는 Compression 항목이 나오고 바로 뒤에는 길이로 인한 고정값이 명시되기 때문이다.
alert tcp any any -> any any (msg:"chromium based"; flow:established,to_server; content:"|16 03|"; content:"|01 00|"; byte_extract:1,2,grease,relative; byte_test:1,=,grease,0,relative; content:"|00 00|"; distance:0; within:2; content:"|00 00|"; distance:-4; within:2; )
현재 정의된 GREASE필드 중 일부가 새로운 프로토콜이나 CipherSuite로 사용되어 다른 브라우저에 추가되면, 이러한 룰들은 사용하지 못하는것이 아닌가? 라고 할수 있다. 하지만 이는 새로운 프로토콜 등이 정의되고 나서 생각할 문제이지 지금에서 생각할 문제는 아니다.
이 룰들은 사실상 모든 TLS ClientHello 메시지를 식별하기 때문에 IPS 모드에서는 부정적일 수 있다.