* 소프트웨어의 필요성
- 모든 정보보안은 소프트웨어로 구현이 된다.
- 소프트웨어가 공격받게 되면 소프트웨어를 구성하는 프로토콜, 보안이 완벽해도 깨지게 된다.
- 소프트웨어는 보안 취약성의 시작점이 된다.
> 거의 대부분의 시스템은 소프트웨어로 구현되기 때문에...
* 나쁜 소프트웨어
- 잘 못만든 소프트웨어
- 나쁜 소프트웨어는 어디에서나 존재한다.
- 의도적으로 만든 나쁜 소프트웨어(Malware)와 예기치 못한 오류를 가진 소프트웨어가 있다.
- 공격자는 소프트웨어의 에러와 결함을 적극적으로 찾는다.
- 소프트웨어의 복잡성은 보안을 취약하게 한다.
> 복잡성은 보안의 적이다.
* Topic
- 비의도적 결함 : 프로그램 결함
> 버퍼 오버플로우
> 불완전한 중재
> Race conditions
- 의도적 결함 : 악성 소프트웨어
> 바이러스
> Worms
> Malware
* 프로그램 결함(flaw)
- Error : 프로그램을 할때의 실수
- Fault : 에러에 의해 부정확한 상태에 도달
- Failure : Fault가 쌓이거나 영향을 주어 시스템이 예상된 동작에서 벗어난 상태가 되게 한다.
- 이 세가지 경우 모두를 flaw : 프로그램 결함 이라고 한다.
※ 안전한 소프트웨어
- 프로그램이 의도한대로 수행하는 것을 보장 / 의도된 것만 수행하고 다른 것은 수행하지 않는 것
ⓐ Buffer Overflow
- 주어진 메모리의 범위를 넘어서 다른 데이터를 덮어 씌우는 것
- 메모리 구조를 이용하여 특정 행동을 하게 하거나, 의도하지 않는 행동을 하게 된다.
- 이는 공격자에게 실행시키고 싶은 어떠한 코드든지 모두 실행시키는 Code injection을 발생 시킨다.
- 공격자는 실행할 위치를 찾기 힘들기 때문에 스택을 분쇄하는 작업을 한다.
> 공격자가 심은 코드가 어느 주소에 있는지 위치를 찾기 힘들다.
> 스택에서 return부분이 어디에 존재하는지 찾기 힘들다.
> 스택 분쇄 : evil Code앞에 NOP(None operation) "착륙점"을 무수하게 많이 심어 놓는다.
> 스택 분쇄 : 또한, 다수의 ret을 삽입한다. ret 지점은 상위 아무 주소중 아무 곳(높은 곳)을 선택
> 스택 분쇄 : 어느 위치에 도착한 실행코드는 NOP에 의해 evil Code까지 가서 공격자가 심어 놓은 오류를 실행시키게 된다.
- 스택 분쇄는 반복적인 시행이 요구 된다. 또한, 메모리상에 잘 정리가 되어 있어야 한다.
- 스택 분쇄(Stack Smashing)의 예는 시디키가 필요한 시스템에서 return위치를 변형하여 인증과정을 건너 띄는 것.
> 프로그램을 disassemble하여 return위치(인증과정이 완료되는 위치로)를 발견 및 이를 이용하여 공격을 한다.
- Stack smashing 예방법
1) non-executable stack 사용 : 완전한 해결방법은 아니다.
2) 안전한 언어를 사용 / Java or C# : runtime때 자동적으로 조사를 한다.
> 하지만 이러한 언어 사용은 성능을 저하 시킨다.
3) 안전한 C함수를 사용한다. 안전하지 않은 함수는 안전한 버전을 가지고 있다. strcpy vs strncpy
4) canary 존재
> run-time시 스택을 조사하는 역할을 해주며, stack return위에 canary를 push해준다.
> 이는 일정한 상수 값으로, return값에 다를 수 있다. overflow시 사용자에게 알려준다.
> MS c++에 buffer security check 기능으로 추가되 있음
> canary가 건드려지면, 사용자에게 이벤트 핸들러가 넘어가게된다.
(handler code가 공격자에 의해 변경될 수 있기 때문에 이는 안전하지 않도고 할 수 있다.)
- 90년대를 대표하는 공격으로 예방가능한 오류이다. 하지만, 이 공격은 앞으로도 계속 지속될 것이다.
ⓑ Incomplete Mediation(완전하지 않은 중재)
- 불안전한 중재는 함수를 수행하는데 검증을 하지 않아 오류를 발생하는 경우를 말한다.
ex) strcpy(buffer1, buffer2); // buffer2의 길이가 더 길면 에러... 이를 검사해줘야하지만, 하지 않게되면 불안전한 중재
- Linux kernel은 많은 buffer overflow문제가 발생하는데 이의 대부분은 incomplete mediation에 의해 발생한다.
> 이러한 문제를 찾는 툴이 존재하며, 이를 발견 많이 수정해나가고 있다.
> 공격자 또한 툴을 이용하여 중재 문제지점을 발견하여 공격에 이용할 수 있다.
ⓒ Race condition
- security process들은 한번에 처리되야 한다.(atomic)
- security ciritical process가 여러단계로 수행되면 Race condition이 발생할 수 있다.
ex) Linux mkdir은 2단계로 행동을 하고 있다. 명령어가 atomic하지 않다.
> 공격자는 이에 대해서 끼어들기를 통해 공격이 가능하지만, 이 시간을 예측하기는 너무 힘들다.
(위 예는 실질적인 레이스 컨디션 이야기는 아니다.)
- race conditions은 흔히 발생하지만, 공격에 이용하기는 힘들다.
- security critical process를 atomic으로 만들면 예방이 가능하다.