DB 보안 - Prevention of inference(추론 방지)

2022. 1. 9. 01:23보안 연구/WEB

반응형

 

본 티스토리 블로그는 PC에 최적화되어 있습니다.

모바일 유저분들은 아래 네이버 블로그를 이용해 주세요

 

 

DB 보안 - Prevention of inference(추론 방지)

본 네이버 블로그는 모바일에 최적화되어 있습니다. PC 유저분들은 아래 티스토리 블로그를 이용해 주세...

blog.naver.com

 

 

안녕하세요! ICMP입니다!

이번 포스팅은 지나가다 읽었던 DB 보안 내용 중 궁금했던 부분이 존재해서 개인적으로 자료조사를 할 겸 이렇게 기록을 남기게 되었습니다.

 

다소 흐름이 어색하더라도 양해 부탁드리겠습니다!

그러 바로 본론으로!!!

 


 

DB 파트 부분의 정보보안 기사를 공부하거나 혹은 보안 매뉴얼을 보게 되면 요구사항으로서 다음과 같은 공통조건이 제시되어 있습니다.

 

1. 부적절한 접근 방지

- 인가된 사용자를 제외한 불필요한 접근 및 비인가자의 접속을 차단해야 한다.

2. 추론 방지

- 일부 데이터를 활용하여 다른 내용(비밀 데이터)을 추론하는 것을 막아야 한다.

3. 무결성 보장

- DBMS의 내부적인 처리 과정 중에서도 내용적, 논리적 일관성을 보장해야 한다.

4. 감사 기능

- DB의 접근과 활동에 대한 모든 행위들은 기록되어야 한다.

5. 사용자 인증

- 운영체제 사용과는 별개로 DBMS는 보다 엄격한 개별 인증 절차를 수행해야 한다.

 

WEB CTF 문제를 풀면서 쿼리 추측이나 동작 과정 유추 등은 있었지만, 결괏값에 따른 일부 데이터를 활용하여 다른 데이터 값을 추정해 내는 경우는 제 경험상 없었습니다.

(어쩌면 문제를 거의 안 푼 것일 수도 있습니다...)

 

 

 

추론 공격의 예시를 들자면 다음과 같습니다.

 

웹 사이트에서 요청 가능한 쿼리는 다음과 같다고 하자.
A : 회사의 물품 재고
B : 재고의 총 가격(금액)
C : 재고 물품 1개당 가격(금액)

 

만약 C 쿼리문이 관리자(마스터) 권한을 가진 사람만 요청 및 확인이 가능하다고 A, B 쿼리문은 누구나 요청 및 확인이 가능하다고 가정하겠습니다.

이때 공격자는 A, B 쿼리문의 정보를 얻어서 (B 쿼리문의 결과) / (A 쿼리문의 결과) = 재고 물품 1개당 가격정보를 추론할 수 있습니다.

 

즉, 추론 공격이 발생하는 원인은 잘못된 쿼리 및 DB 논리설계라고 볼 수 있습니다.

 

구글링을 통해서 조금 더 자세한 정보를 알아본 결과, 더 정밀한 공격을 수행하기 위한 여러 방법론이 존재하고 있었는데 오늘은 이 부분을 조금 더 공부해 볼까 합니다.

 

 

- 여기부터는 Wateroo University의 Cryptography, Security, and Privacy (CrySP) 연구팀의 강의를 인용하였음을 알립니다.

해당 자료에서는 추론 공격을 크게 통계 추론 공격과 트랙커(Tracker) 공격으로 분류하고 있으므로 의미상의 혼동을 방지하기 위해 그대로 서술하도록 하겠습니다.


 

- Statistical Inference Attacks (통계적 추론 공격)

앞서 소개 드린 예시가 전형적인 통계적 추론 공격이라고 볼 수 있습니다.

통계적 성질을 활용하여 비밀 데이터들을 유출(leak) 하는 것이 바로 이 공격의 핵심이라고 할 수 있습니다.

 

 

아래는 가장 많이 활용되는 예시입니다.

 

1) Sum()

-> 공격자가 1개만의 레코드를 수정할 수 있거나 일련의 레코드를 수정할 수 있을 경우 상당히 민감한 정보를 유출하는데 활용할 수 있습니다.

* select Sum(Grade);

* select Sum(Grade) where name != "victim_name";

 

따라서 두 쿼리문의 차이 값을 이용하여 victim_name의 Grade 값을 유추할 수 있습니다.

 

2) mean & count

-> 앞서 들어가기 전에 소개한 예시에서 활용한 방법입니다.

     mean(평균) = sum(총합) / count(총개수)

 

 

3) median

-> 경우에 따라서는 중앙값도 어떻게 쿼리를 처리하냐에 따라 공격에 유용하게 활용될 수 있습니다.

    추가적인 설명은 여기까지만 하고 다음 공격 방식에 대해 설명해 드리도록 하겠습니다.

 

 

 

- Tracker Attack(트래커 어택)

privitar이라는 데이터 보안 솔루션 제작 회사에서는 해당 공격을 다음과 같이 정의하고 있습니다.

A tracker attack is where an attacker can isolate an individual by making multiple aggregate queries.
(Tracker Attack은 공격자가 여러 개의 집계 쿼리를 만들어 개인을 격리시킬 수 있는 공격이다.)

 

여기서 여러 개의 집계 쿼리란 어떤 쿼리를 의미하는 것일 가요?

그리고 이러한 쿼리를 이용해 개개인을 격리시킨다는 것은 어떠한 행위를 말하는 것일 가요? 한번 알아보도록 하겠습니다.

 

- 예시

k : 임의의 수

N : DB에 있는 레코드의 수

 

DBMS를 공격하려고 확인해 보니, 쿼리 결과 반환되는 레코드 수가 k보다 작거나 N-k보다 크면 클라이언트에게 반환 및 출력을 거부한다고 합니다.

우리는 똑똑한 짱 해커이기에 조건을 우회하여 반환 레코드를 leak 해야 합니다.

요청하는 레코드의 수를 x라고 하면 다음과 같은 의사 코드를 작성할 수 있습니다.

if(x<k || x>N-k) 
     return NULL;

else
     return query.result();
 

그럼 우리가 2k 또는 N-2k를 입력할 경우 조건이 만족되어 원하는 레코드 결과를 확인할 수 있습니다.

반대로 조건에 맞지 않아서 거부되는 경우도 존재하겠죠?

 

입력쿼리가 조건에 맞아서 반환 및 출력이 되는 x 쿼리들의 집합을 T, 조건에 맞지 않아서 거부되는 x 쿼리들의 집합을 C라고 설정하겠습니다.

 

또한, 우리가 입력한 쿼리의 결과를 q()라 하고 모든 레코드의 집합을 S라고 한다면, 벤다이어그램을 활용하면 이들의 관계를 아래와 같이 표현할 수 있습니다.

 

1) 반환되는 레코드 수가 k 개 미만인 경우

q(C) = q(C or T) + q(C or not T) – q(S)

 

2) 반환되는 레코드 수가 N-k 개 초과할 경우

q(C) = 2 * q(S) - q(not C or T) - q(not C or not T)

 

즉, 같은 결과를 반환하더라도 요청하는 쿼리문을 우리가 원하는 형태로 변환이 가능하다는 점이 가장 핵심입니다.

상황에 따라서는 간단한 로직이나 선형대수적인 지식을 기반으로 허용된 다수의 쿼리문을 이용하여 허가되지 않은 쿼리문을 요청할 수 있습니다.

 

그럼 이 같은 공격을 막으려면 어떻게 해야 할까요?

DB를 보호 관점에서 바라볼 경우 다양한 방어 수단이 존재하는데, 각각 설명드리도록 하겠습니다.

 

 

1. Suppression

DB 보안에서 Suppression은 말 그대로 은폐하는 것을 말합니다.

추론 공격에 활용될 여지가 있는 정보들을 없애거나 숨기는 것을 말합니다.(너무 당연한 말 같죠?)

 

2. Concealing

쿼리 결과로 반환된 값은 실제 값으로 전달하되 정확한 수치적 값이 아닌 모호한 값으로 전달하게 하는 것입니다.

 

이외에도 제어 관점에서는 n-item k-percent rule, Random data perturbation, Query analysis 등이 있으며, 구조적인 관점에서는 Multilevel Security (MLS) Databases가 존재합니다.

 

 

이들을 모두 다루고 싶지만, 아직 DB 지식이 부족해서 직접적인 실습이 이루어지지 못하기에 오늘 다루지 못한 내용은 다음에 기회가 되면 포스팅을 진행하도록 하겠습니다.

 

필력이 부족한 글을 끝까지 읽어주셔서 감사합니다.

틀린 부분이 존재하면 지적 적극적으로 수용하겠습니다!

 

이상! ICMP였습니다!

감사합니다!

 

반응형

'보안 연구 > WEB' 카테고리의 다른 글

SPAM - basic analysis  (0) 2022.02.27
(웹 보안) 기초 - 웹사이트 제작 2일차  (0) 2020.10.15
(웹 보안) 기초 - 웝사이트 제작 1일차  (0) 2020.10.10