'Computer Science/Computer Security'에 해당되는 글 6건

1. Overview

접근제어(Access Control)란??

접근제어는 자원에 대한 권한이 없는 주체(Subject)가 해당 자원의 사용을 막는 것을 의미한다.

접근제어를 하기 위해서 주체를 구별하기 위한 Identification과 본인 여부를 확인하는 인증 절차가 필요하다.

특히 인증의 성공 여부에 따라 리소스에 접근할 권한을 줄지 안 줄지 결정되므로 인증이 핵심 절차이다.

주체(Subject)는 컴퓨터를 사용하는 사람, 그룹, 프로세스, 컴퓨터와 같이 정보를 요청하는 요소이며,

객체(Object)는 파일이나 폴더, 디바이스, 메모리 등 정보를 가지고 있는 요소이다. 

주체는 접근 권한에 따라 객체를 읽거나, 쓰기, 실행이 가능하며 권한은 객체별로 다른 형태로 부여한다.

요구사항

- 신뢰가능한 입력(reliable input) : 신뢰가능함은 인증을 통과한 주체가 행하는 입력을 의미한다.

- 포괄적 vs 세분화 : 권한의 범위를 어느 수준까지 설정하는가 문제

- 최소 권한 : 주체에게 너무 큰 권한을 부여하면 시스템의 문제의 여지가 될 수 있다.

- 열린 정책 vs 닫힌 정책 / 정책 간 충돌 문제

- 정책 관리 : 관리자만이 정책을 변경할 수 있다.

- 동시성 제어 : 하나의 객체에 여러 주체가 동시에 접근할 경우 어떻게 처리할지 문제

- 의무의 분리 : 중요한 행위는 반드시 두 개이상의 user나 권한으로 나누어서 실행한다.

2. DAC(Discretionary Acess Control)

주인장 맘대로

자원의 주인이 해당 자원에 대한 다른 사람들의 권한을 결정하여 접근 제어를 하는 방법이다.

따라서 이 방법을 사용하기 위해서 각자를 구별할 ID와 해당 자원의 소유권, 그리고 다른 유저에게 분배된 권한을 정리할 파일이 필요하다. 권한을 저장하는 방법은 Access Control List, Capability List, Access Matrix가 있다. Access Matrix의 경우에는 사용자가 많고 자원들이 많은 실제 상용 시스템에서 사용하면 공란이 많은 희소 행렬의 형태라 공간 낭비가 심해 사용하지 않는다.

Access Control List vs Capability List

ACLs는 자원에 대하여 각 사용자들의 권한을 저장하는 방법이고 CL은 반대로 사용자에 대하여 각 자원들의 권한을 저장하는 방법이다. 다시 말해 ACLs는 자원 중심, CL은 사용자 중심의 저장 방법이다. 따라서 사용자에 비해 자원이 많은 개인용 PC 같은 환경에서는 ACLs, 사용자의 수가 많은 웹 서버같은 환경에서는 CL이 더욱 유용한 방법이다. 

DAC 장점

- 사용자가 접근 권한을 관리 할 수 있어서 보안 관리자가 업무가 줄어 든다.

- 권한을 수정이 쉽고 새로운 권한을 적용하기 쉽다.

DAC 단점

- 위의 그림처럼 권한을 부여한 사용자의 의도하지 않은 대로 정보가 흘러갈 수 있다.

- 루트의 권한이 너무 강력하다. 

- 주체와 객체의 수가 증가한다면 복잡해지고 크기가 커지는 문제도 있다.

- 소유자를 쉽게 변경이 가능하다는 점을 악용한 프로그램들도 많다 

Unix / Linux의 파일 시스템

리눅스의 파일 시스템의 정보는 inode 저장된다. inode에는 하나의 파일 또는 디렉터리의  UID, GID, 소유권이 명시 되어있으며 12개의 비트로 특수권한 / 읽기 / 쓰기 / 실행 권한을 표기한다. 이 inode들은 디스크 상에 inode 테이블이나 리스트에 저장이 되어진다. 그리고 파일을 열면 해당 파일의 inode는 메인 메모리에 상주하는 inode 테이블에 저장된다. 

DAC 취약점 실습

위 그림은 file1의 소유주 csos가 user1에게 읽기 권한을 부여하는 과정이다.

리눅스에서 setfacl 또는 chacl 명령어로 파일 시스템 상의 ACL을 변경할 수 있고 getfacl 명령어로 해당 파일의 ACL정보를 확인 할 수 있다. 파일의 소유자의 UID, GID 정보와 각 사용자와 그룹에 대하여 권한, 마스크 정보도 추가된 확장된 ACL을 사용한다는 것을 알 수 있다. 파일 시스템에 접근하는 경우 파일의 ACL을 확인하여 소유자 -> 지정한 유저 -> 그룹 -> 외부자로 순으로 연산 처리한다.

user1으로 접속을 변경하고 csos가 읽기 권한을 준 file1을 복사하여 user1의 영역으로 복사하였다. 이제 user1은 file1의 사본 file2의 소유자이므로 file1에 대한 모든 권한을 행사할 수 있다. 이처럼 DAC는 원 소유자 csos의 의도와 다르게 흐름을 변경할 수 있는 취약점이 있다.

1. Rainbow Table attack

답지를 들고 있단다.

앞서 비밀번호는 대부분 해시함수를 사용하여 그 결과 값을 데이터베이스에 저장한다고 했다. 따라서 복호화가 불가능한 상태라 평문(비밀번호)의 내용을 관리자한테까지 숨길 수 있는 장점을 가지고 있다. 이에 따라 공격자들은 사전에 해쉬함수에 입력한 값과 해쉬 결과 값을 저장한 일종의 정답지(Rainbow Table)를 가지고 비밀번호를 확인 할 수 있게 되었다. 이런 공격 우연하게 같은 비밀번호를 사용하는 경우에 여러 계정이 동시에 피해를 볼 수 있는 단점이 있다. 따라서 이 공격에 대안으로 Salted hash가 등장하였다.

2. Salted hashed

양념을 촵촵촵

기존에는 패스워드만 해시함수에 통과시켰으나 최근에는 가입 시간이나 난수(Random Number)를 비밀번호와 같이 해시 값에 포함한다. 이 때 추가적으로 포함된 가입 시간이나 난수를 Salt라고 한다. 치킨에다가 양념을 어떤 것을 사용하냐에 따라 맛이 달라지 듯이 서로 다른 계정이 같은 비밀번호를 사용하더라도 Salt가 다르면 완전 다른 해시 값이 달라지며, 설령 같은 해시 값을 같더라 하여도 Salt 값이 전혀 다르기 때문에 평문을 유추하기 힘들다. 이 Salt는 해쉬 결과 또는 Salt 평문을 패스워드 관리 테이블에 같이 보관한다.

Salted hash의 경우 Salt의 길이가 길면 길수록 무차별 대입공격이 강력하다. OpenBSD는 Blowfish라는 블록 암호화 기법을 가지고 있으며 128bit의 Salt를 사용하여 192비트의 해시 값을 만들어 낸다.

시간을 끌자

해시 함수는 암호화보다 소요하는 시간이 짧다. 따라서 암호문을 무차별 대입으로 푸는 것보다 해시함수에 무차별로 대입하는 것이 소모하는 시간이 짧아 이 시간을 늘려야 할 필요성이 있다. 이에 따라 개발자들은 해시함수를 1000번이상 반복으로 실행하여 고의적으로 시간을 늦추려 하고 있다. 

3. Bloom Filter

사용자 교육의 한계

뉴스에서 보안 사고가 발생하여도, 청개구리 같은 사용자들이 많다. 비밀번호를 길고 자연어 사용을 제한하고 취약한 비밀번호 사용을 금지해도 외우기 귀찮고 손에 안 익는 비밀번호를 사용하기 싫어서 무시하고 사용하며, 일정 주기마다 비밀번호를 변경하라는 메세지가 뜨면 "다음에 할게요~ㅎㅎ" 하고 그냥 넘어가 버리는 경우도 많다. 따라서 말 안듣는 사용자를 교육시키기보다 애시당초 시스템에서 보안이 취약한 비밀번호에 대하여 거절을 하게 만든다.

너만 갖고 있냐?? 나도 갖고 있어!!

Brute Force Attack

무차별 대입 공격은 사용자가 입력할 수 있는 모든 글자에 대하여 하나하나 대입을 하면서 비밀번호를 풀어 내는 방법이다. 예전에 여자친구가 아이폰 백업 비밀번호를 잃어 버린적이 있어서 풀어주기 위해 툴을 사용한 적이 있는데 대부분의 툴들은 무차별 대입공격을 기반으로 한다. 특수문자와 영어 대소문자, 숫자로 구성된 비밀번호 9자리를 푸는데 요구되는 시간이 1030년이라고 뜬 적이 있다. 이처럼 무차별 대입공격에 강한 비밀번호가 되기 위해서는 비밀번호를 길고 복잡하게 만들어야 할 필요가 있다. 최근에는 빠른 연산이 가능한 GPU와 멀티 쓰레드처럼 병렬처리를 사용하여 시간을 단축하는 기법도 사용한다.

Dictionary Attack

비밀번호 크랙툴 중에 기본적으로 사전 공격이 있는 툴도 있는데. 공격자가 무차별 대입 공격에서 시간이 많이 걸리는 점을 우회하기 위해서 착안한 방법이다. 이 사전 공격은 공격자가 대부분의 사람들은 자연어를 이용하여 비밀번호를 만든다는 점과 사람들이 자주 사용하는 비밀번호 정보를 수집하여 사전으로 만들고 그 사전의 단어를 기반으로 대입을 하여 비밀번호를 푸는 방법을 말한다. 이 방법을 사용하면 무차별 대입공격보다 한참 적은 시도로 비밀번호를 크랙할 수 있는 장점이 있다. 

Rainbow Table Attack

비밀번호는 대부분 암호화 해시 함수를 사용한 결과 값을 데이터베이스에 저장이 된다. 해시 함수는 일방향 함수로 암호화 과정만 있고 복호화 과정이 없는 특징이 있어서 해당 값을 복호화하는 것은 불가능하다. 하지만 공격자가 해시함수에 다양한 값을 입력하여 얻은 해시 값들을 정리해놓은 테이블(Rainbow Table)이 있다면 해당 데이터 베이스에서 비밀번호를 알아 낼 수도 있다. 또한 우연하게 같은 비밀번호를 사용하는 사람들이 있다면 데이터 베이스에 저장된 해시 값이 같으므로 하나의 비밀번호를 크랙하는 동시에 여러 계정이 폭발하는 문제도 발생할 수 있다.

Exploiting multiple password use

워낙 많은 사이트와 SNS가 있다보니 같은 아이디에 같은 패스워드를 사용하는 경우가 많다. 따라서 만약 하나의 사이트의 아이디, 패스워드가 크랙이 되면 연쇄적으로 다른 사이트도 피해를 볼 수 있다. 가급적 비밀번호를 사이트 마다 다른 것을 쓰는 것을 권장하는 이유다.  

Workstation hijacking

PC방에서 컴퓨터를 켜놓고 잠깐 자리를 비운사이 아직 로그인되어 있는 사이트에 공격자가 앉아서 공격을 하는 방법. 

(좀 성격 안 좋은 형님들이 동생들이 자리 비운 사이에 아이템을 다 팔아버리거나 버려버리는...)

자리를 비우는 경우에는 화면보호기나 컴퓨터를 끄고 가는 것이 좋다.

Exploiting User Mistake

간혹 로그인할 때 아이디를 입력하는 곳에 비밀번호를 입력하여 로그인 버튼을 누르는 경우가 있는데, 로그나 암호화 되지 않은 패킷을 캡쳐하여 비밀번호를 획득할 수 있다. 

보안 카드의 번호를 전부 다 입력하라, 주민등록번호를 말해달라, 비밀번호를 말해달라 등 컴퓨터적인 기술을 이용한 것이 아니라 사회 공학적인 요소를 활용하여 상대방을 속여서 비밀번호 등을 획득하는 방법. 때로는 카페이나 도서관 등에서 대화하는 내용을 수집하여 개인정보를 획득하고 비밀번호를 얻는 방법도 있다.  

1. 필요성

사용자 식별의 필요성

회원가입 과정을 생각해보면 ID 중복 체크를 반드시하여 중복되는 ID에 대한 사용을 금지하는 과정을 쉽게 볼 수 있을 것이다. 왜냐하면 멀티 유저 시스템에서는 각각 유저들에 대한 권한이 다르게 설정되어 있기 때문에 사용자간의 식별을 위해서 중복을 피한다. 예전에는 영문과 숫자 조합의 아이디를 사용하였지만 최근에는 이메일이나 휴대전화번호도 중복이 되지 않는 점을 착안하여 아이디로 사용하기도 한다. 

사용자 인증의 필요성

이제 아이디를 정상적으로 만들어 회원가입을 한 후 해당 사이트에 로그인을 하고자 한다. 아이디를 입력하고 우리는 비밀번호를 입력한다. 비밀번호로 나 자신이 해당 계정의 주인임을 인증하는 것이다. 식별과 비슷한 이유로 사용자 간의 권한은 서로 다르기 때문에 해당 권한을 사용할 사람이 맞는지 아닌지를 입증을 할 필요가 있다. 

2. 인증 방법의 분류

Something you know

당신만이 알 수 있는 내용으로 사용자를 인증하는 방법이다. 대표적으로 Password나 Pin이 있으며, 간혹 비밀번호나 아이디를 찾고자 할 때 "당신이 가장 소중하게 여기는 것은?"이라는 질문을 하는 경우도 해당한다. 

이 방법의 장점은  주인이 분실하거나 유출이 의심될 때 쉽게 비밀번호를 변경을 할 수 있다는 점이다. 그에 반해 단점은 본인이 아닌 다른 사람이 해당 비밀번호를 알고 있다면 쉽게 접속하여 권한을 남용하여 시스템에 해를 입힐 수 있다. 따라서 비밀번호를 인증으로 사용하는 경우에는 저장할 때 암호화 해시를 사용하는 등 비밀번호의 보관에 신경을 더욱 쓸 필요가 있다.

Something you have

은행에서 공인 인증서를 발급 받으면 보안카드나 OTP를 발급 받을 수 있다. 또는 회사에 입사하면 사원증을 발급 받는데 그것을 이용하면 회사의 입구에 카드를 대어 사원을 인증하는 경우도 본 적이 있을 것이다. 

이처럼 개인이 가지고 있는 것으로 인증을 하는 방법도 있다. 이 방법은 해당 기기를 분실 / 도난 당하지 않는다면 안전하게 개인을 인증할 수 있는 장점이 있다.

Something you are

요즘 최신 스마트폰에 내장된 지문 / 홍채 인식처럼 생채정보를 활용하여 인증을 하는 방식이다. 사용자만이 가질 수 있는 것을 이용하기 때문에 해당 사용자만이 사용할 수 있는 장점이 있어 강력하지만 만약 유출이 되어진다면 변경이 불가능하다. 일반적으로 홍채의 경우가 가장 정확성이 뛰어나지만 비용적으로 아직 비싼 기술이다.

바이오 인증 과정은 우선 사용자는 자신의 신체 특징(지문, 홍채)을 입력하면 컴퓨터에서 특징점을 분석하여 데이터베이스에 저장한다. 사용자는 인증이 필요한 경우 해당 인식기에 자기의 지문, 홍채 등을 입력하면 데이터 베이스에 저장된 특징점과 입력된 특징점을 비교하여 해당사람이 맞는지 아닌지를 인증한다. 수사와 같이 특수한 경우에는 데이터 베이스에 범죄자로 추정되는 지문을 입력하여 특징점과 데이터베이스 내부의 모든 데이터와 특징점과 비교하여 해당 사람이 누구인지를 확인하는 절차를 가진다.

Something you are/not

최근에 나의 페이스북이 내가 사는 곳이 아닌 엉뚱한 곳에서 접속을 한 이력이 있다고 페이스북에서 경고메세지를 보내 주었다. IP나 Mac Address로 평소에 접속하는 곳이 아닌 엉뚱한 곳에서 접속하는 경우 당신이 맞는지 아닌지 확인을 해주는 기능이 페이스북에 있었나보다.. 이처럼 사용자의 Mac 주소나 IP 주소로도 인증이 가능하며 이 경우는 이동이 잦은 경우에는 IP주소가 달라지고 다양한 기기를 사용하면 Mac 주소의 변별력이 떨어지므로 이동을 하지 않거나 해당 디바이스가 고정된 경우에 사용하는 것이 좋다.

3. 스마트 카드

Memory 카드

Memory 카드는 데이터를 저장할 수는 있지만 연산이 불가능한 카드다. 일반적으로 카드의 자기선이나 내부의 메모리 칩에 데이터를 저장되어 있으며 카드를 사용할 때 비밀번호를 입력하는 것으로 보안을 강화한다. 우리가 은행에서 사용하는 신용카드가 이와 같은 형태를 가지고 있으며 비밀번호 4자리를 사용하는 대신 입력의 횟수를 제한하여 무차별 대입 공격을 방지한다.

스마트 토큰(OTP)

데이터의 저장 뿐만 아니라 마이크로프로세서가 내장되어 있어 연산이 가능하다. 일반적으로 키패드와 함께 있어 키패드로 비밀번호를 입력하면 내부 연산으로 One Time Password(OTP)를 생성하여 디스플레이에 보여준다. OTP는 임시적인 비밀번호로 한번 사용하게 되면 Dynamic Password Generator에 의해 새로운 일회용 비밀번호를 생성하는 방법인 Challenge-response를 사용한다. 

스마트 카드

스마트 토큰의 기능과 메모리 카드의 기능을 한 카드에 모은 것이 스마트 카드이다. 메모리가 있어서 데이터를 저장할 수 있으며 프로세서가 있어서 연산에 가능하며 입출력장치도 가지고 있다. 메모리는 카드의 유통기한동안 바뀌지 않는 데이터를 저장하는 ROM, 어플리케이션 데이터와 프로그램을 가지고 있는 EEPROM, 어플리케이션이 수행할때 임시적으로 데이터를 생성하는 RAM을 가지고 있다.

1. 암호화

암호화의 목적

암호화는 정보 노출(information disclosure)를 막기 위한 도구로 사용한다. 사용자는 프로그램이나 인터넷을 통하여 다양한 데이터를 주고 받는다. 이 과정을 그냥 평문으로 작성되면 도청을 하는 제3자에 의해 악용될 가능성이 있다. 따라서 암호화를 하여 키를 가지고 있지 않은 제 3자가 중간에서 도청을 하더라도 평문의 내용을 알 수 없고 키를 가지고 있는 대상에게만 평문의 내용을 확인하기 위해 암호화 기법을 사용한다. 

암호의 역사

암호화의 역사는 고대 로마시대의 카이사르 암호에서 시작한다. 평문의 글자의 위치를 바꿔가면서 키를 가지고 있지 않은 사람에게는 평문의 내용을 쉽게 알 수 없게 한다. 하지만 키의 크기가 작아서 무차별 대입공격에 취약하고 영어 문자의 특징상 자주 쓰는 알파벳이 있어서 사전 공격에 취약하다는 단점이 있었다.  시간이 지나 조금 더 발전된 암호가 Vigenere cipher다. 키가 되는 문자와 평문의 한 글자씩 사전에 준비한 표를 통하여 바꿔나가는 방법이다. 

대칭키 / 비대칭키

대칭키는 송신자와 수신자가 동일한 키를 가지고 있다. 따라서 암호화와 복호화를 같은 키를 통하여 수행한다. 속도적인 측면에서 비대칭키보다 매우 뛰어나지만 키를 어떻게 분배를 할 것인가에 대한 문제가 있다. 

비대칭키는 송신자와 수신자가 서로 다른 키를 가지고 있어 암호화와 복호화의 키가 서로 다르다는 특징이 있다. 이 알고리즘에서 수신자는 개인 키(private key)는 자신이 가진 채 비밀로 하고 공개 키(public key)를 인증 센터에 등록한다. 그리하여 송신자는 수신자의 공개 키로 암호화하여 수신자에게 전송하면 수신자는 개인 키로 복호화하여 원문을 확인 할 수 있다. 따라서 개인 키를 모르는 공격자는 해당 내용을 알 수 없다.  

키 분배를 해결할 수 있다는 점에서는 우수하지만 속도가 느려 현재는 비대칭키 알고리즘으로 대칭키의 키 분배를 한 후 대칭키 알고리즘을 통하여 통신을 한다. 대표적인 알고리즘으로 대칭키는 DES 알고리즘, 비대칭키는 AES 알고리즘이 있다. 

2. 해시 함수

해시의 목적과 특징

해시는 데이터 변조를 막기 위한 조치로 만들어진 기법이다. 해시는 입력의 크기와 상관없이 일정한 길이의 출력 값을 출력하는 것이 특징이고 한 글자라도 변조가 발생하면 해시 값 전체가 변화하는 특징이 있다. 이러한 특징으로 중간에 데이터 변조가 발생하였는지 여부를 확인할 수 있다. 대표적인 알고리즘으로 SHA 알고리즘이 있다.

암호화 vs 해시함수

해시와 암호화 도구와 큰 차이점은 역함수가 없다는 점. 따라서 복호화를 통하여 평문을 확인할 수 있는 암호화 도구들과는 달리 해시 함수는 복호화를 할 수가 없다는 특징이 있다. 이러한 특징을 잘 볼 수 있는 대표적인 사례가 패스워드 관리다. 비밀번호를 까먹어서 비밀번호 찾기를 누르고 각 종 본인 인증을 끝나면 비밀번호를 알려주는 것이 아니라 새로운 비밀번호를 작성할 것을 요청한다. 왜냐하면 비밀번호 평문을 데이터베이스에 저장한 것이 아니라 해시함수를 거친 결과물을 데이터베이스에 저장해서 관리자도 알 수 없고 복호화 자체를 할 수 없어서 원래 비밀번호가 뭔지 알 수 없기 때문이다.

1. Buffer Overflow

가장 기본이 되는 예제로 보면 변수 c는 char형 8개를 담을 수 있는 공간이다. 이 곳에 8개 이하의 데이터를 보관하는 것은 문제가 되지 않는다. 근데 9개의 데이터를 넣는 순간 c의 영역을 넘어 다른 공간까지 데이터가 저장되는 것을 알 수 있다. 이처럼 버퍼 오버플로우는 입력의 한계를 충분히 확인하지 않은 API 사용으로 버퍼에 근접한 메모리 주소에 있는 데이터 값을 변경할 때 발생한다. 대표적인 API로는 scanf(), gets(), strcat(), strcpy() 등이 있다. 최근에 나온 컴파일러는 취약한 API에 대하여 사용을 제한하거나 경고하고 있다.

메모리에서 스택은 고드름처럼 위에서 성장하는 하며 함수가 호출되면 매게변수 - 리턴 주소 - 지역변수 순으로 스택에 쌓인다. 반면에 버퍼는 거꾸로 위로 타고 올라가면서 성장한다. 따라서 일정 수준 이상을 입력하게 되면 리턴 주소가 변경된다. 이 특성을 이용하여 공격자는 메모리상에 악성 코드를 주소 A에 두고 리턴 주소를 버퍼 오버플로우를 활용하여 A로 변경하여 원하는 프로그램을 수행시킨다. 이러한 악성코드는 시스템 콜로 구성되어 있다.

3. 예방법

범위를 확인하지 않는 API 사용은 하지 않는다.

대표적인 strcat(), strcpy(), scanf()는 입력의 범위를 확인하지 않고 입력시키는 특징 때문에 버퍼 오버플로우에 취약한 모습을 보여준다. strlcat(), strlcpy(), scanf_s() 등으로 대체하여 사용하는 것이 중요하다.

최신의 운영체제를 사용한다.

운영체제가 발전함에 따라 스택 가드, 스택 쉴드, Non-Executable 스택 등 다양한 방어 장치를 이용해 공격자의 공격을 막는다. 또한 컴파일러도 발전함에 따라 범위 밖의 입력에 대하여는 예외로 처리하여 주며 불완전한 API 사용에 대하여 경고나 금지를 하는 등 최신의 컴파일러를 사용하는 것도 좋은 방법이다.