소프트웨어 역공학 (SRE)
- 또는 RCE라고도 부른다.
- 좋은 목적으로 사용되기도 한다.
- 안좋은 목적으로도 사용된다 (ex) 소프트웨어의 해적판)
가정 - 공격자는 실행파일만 가지고 있다. 공격자는 소프트웨어를 이해하고, 취약한 부분을 통해 수정해 본인이 원하는 목적으로 프로그램을 바꾸는 것이 목표이다.
역공학에 사용되는 도구들
- 디스 어셈블러 : 실행파일을 어셈블리 언어로 변형시켜준다. 항상 정확하게 디컴파일 되는 것은 아니다. 또한 디스 어셈블리를 다시 어셈블해 다시 실행파일로 만드는 것도 쉽지 않다. 정적 분석(코드 자체를 이해하기 위함)에 사용된다.
- 디버거 : 코드가 런타임 때 어떻게 동작하는지, 동적 분석을 하기 위해서 사용된다.
- 헥스 에디터 : 16진수 편집기. 실제 패치를 만들기 위한 것이다. 바이너리 파일을 직접적으로 수정하기 위한 도구이다.
- 그 외 : regmon, filemon, vmware...
디버거가 왜 필요한가?
디스어셈블러 같은 경우 정적인 결과만 제공한다. 코드만 제공하기 때문에 머리속에서 동작을 상상해야 하는데, 한계가 존재한다.
디버거는 이러한 한계를 극복하기 위해 동적인 기능을 제공한다. 런타임 때 실제로 어떻게 동작하는지를 볼 수 있다.
문제는 모든 코드들이 정확하게 디스어셈블리 되지 않는다.디스어셈블러와 디버거는 둘다 타겟 소프트웨어를 뭔가 진지하게, 보다 면밀하게 분석하고자 할 때 함께 사용되는 툴이다.
역공학의 예시
)
)
)
)
eax 와 eax를 and 연산한다. eax = 0 일 경우 0 AND 0 = 0
eax = 1일 경우 1 AND 1 = 1이 나오게 된다. 0일 경우에 jz로 분기한다. (시리얼 넘버 맞음!)
test를 XOR로 변경시켜서 항상 0을 반환하도록 한다. XOR은 문자가 같을 경우 0을 반환한다.
0 XOR 0 = 0, 1 XOR 1 = 0 이기 때문에 항상 0을 반환해 항상 jz로 분기하게 된다.
)
어떤 시리얼 넘버를 넣어도 올바른 시리얼 넘버로 인식하게 되었다.
수정된 프로그램을 디스어셈블리 한 결과 test부분이 xor 부분으로 제대로 변경되어 있다.
역공학 공격을 막는 방법
- 안티 디스어셈블리 : 코드의 정적인 뷰에 혼돈을 준다 (쓸데 없는 코드, 분기문을 넣는다.) 목적 코드를 암호화시키거나, 자가 수정하는 코드를 구현한다. 그러나 폴리모픽때와 같이 복호화 코드가 필요하기 때문에 이것이 취약점이 될 수 있다.
- 안티 디버거 : 코드의 동적인 뷰에 혼돈을 준다. (분기문, 스레드 활용). 디버거는 스레드 레벨에서 처리하지 않기 때문에 이를 통해서 혼란을 준다. 프리패칭 상황을 이용한다. (메모리 공간에 먼저 올려놓고 일괄 실행되는 상황)
예) 실제로 inst1 이 inst4를 junk로 덮어씌워지는 동작을 하는데, 프리패칭을 쓰는 경우 디버거의 입장에서는 덮어 씌워졌는지 알 수 없다.
그러나 안티 디버거든 디스 어셈블러든 공격자가 똑똑하면 뚫을 수 있다.
- Tamper-resistance(변조 저항) : 변조된 것을 탐지한다. (패치되면 알 수있도록)
- Code obfuscation (코드 난독화) : 이해하기 힘들게 만든다. 강력한 보안 기법으로 많이 사용되고 있다.
ex) 인증 소프트웨어의 경우, 궁극적으로 인증 결과를 내는 비트값이 잇다.0, 1로 정해지는데 이 1비트와 같은 핵심적인 역할을 하는 부분을 어렵게 만들어서 공격자를 헷갈리도록 만든다. 효과적으로 방어할 수 있다.
Software Cloning
동일한 복사본을 전달할 경우, BOBE의 문제가 있다. Break once, brak everywhere. 한 곳에서의 침해, 한 곳에서의 공격이 모든 곳에서의 침해로 이어진다.
-> Metamorphic software를 사용한다. 소프트웨어를 변종화 시켜서 막을 수 있다. 소프트웨어를 배포할 때, 사용자별로 배포하는 버전들이 조금씩 다르게끔 만들어 BOBE 상황을 막는다. 하나가 뚫림으로서 모두가 뚫리는 상황을 막을 수 있다.
두가지 종류의 변종화가 가능하다.
- 모든 인스턴스가 항상 기능적으로 다른 상황 (아주 특정한 상황에서만 가능)
- 인스턴스는 동일한데 코드 내부적으로만 다른 상황. (현실적으로 그나마 가능)
복제된 소프트웨어를 n개 배포할 때, 변종화 해서 배포한다면 한 곳에서 뚫려도, 나머지 N-1개에선 뚫리지 않는다. 결국 원래 공격했던 것에 비해 n배 만큼의 노력을 해야 한다.
우리는 SRE를 방지할 수 없고, 최선은 BOBE에 저항하는 거고 그리고 저항하는 방법 중에 하나가 이 변종화다.
Digital Rights Management
디지털 콘텐츠에 대한 원격 통제를 제공한다. 정당한 대가를 지불한 사람들만 사용가능하게 하도록 한다. 막기 위한 시도 중 하나로 블록체인이 있다.
- 원격 통제 문제 (remote control problem)
- 지속적인 문제 (Persisten protection)
의 두가지 문제가 있다.
DRM 구현 법
- 명예 시스템 (사람들 믿기..)
- 포기하기 ㅋㅋ ㅠ
- 불완전한 소프트웨어 기반 DRM (Lame software based DRM) : 불완전한 소프트웨어를 배포 후, 대가를 제공하면 완전한 동작을 할 수 있게 한다. 오늘날 drm 시스템의 주요 컨셉 ex) 어도비 포토샵 7일 체험
- 향상된 소프트웨어 기반 DRM : 시큐리티 레벨, 회원 레벨 별로 쓸 수 있는 기능들을 다 정의해서 drm 정책을 적용
- 그외에도 하드웨어 레벨에서 막는 방법, 폐쇄형, 오픈형 시스템에서 막는 방법들이 있다..
암호화하면 안되나요?
공격자가 암호화된 콘텐츠와 복호화된 콘텐츠를 전부 다 가지고 있기 때문에, 즉 공격자가 많은 정보를 가지고 있기 때문에 암호화를 단순히 적용하기에는 한계가 있다.
오늘날의 DRM
- 은폐에 의한 보안 (security by obscurity) : 완전히 막을 수 없기 때문에 최대한 숨긴다. 좋은 보안은 아니다. 공격자들은 키 빼고 암호 체계에서 암호 시스템 내에서 작동되는 모든 것을 알고 있다고 우리가 가정을 하는 kerckhoffs 원칙에 위반된다.
DRM의 한계
아날로그 홀 : 어떻게든 아날로그 형태로 캡처될 수 있다. 모니터의 화면을 카메라로 찍으면 되니까. 즉 절대적인 drm은 불가능하다. 또 구현했어도 sre로 뚫릴 수 있다..
DRM for PDF Documents
- MediaSnap에 의해서 디자인 되었다.
- 지금 많이 사용되는 drm의 모티브 프로토 타입이다.
- 서버와 클라이언트 구조로 되어있다.
서버 :Secure document server (SDS)
클라이언트 : PDF 리더기 plugin 된 소프트웨어- 동작 방법 : PDF 문서를 생성해 암호화 한 후 SDS에 전송. SDS는 지속적인 보호를 적용함. 타인이 이 문서를 요청해 서버에서 문서를 전달하게 됨. 키가 있어야 열 수 있는데, SDS 서버로 인증을 해서 인증될 경우에 키를 받는다. 키를 받아도 특정한 응용프로그램 (클라이언트)로만 pdf 문서를 열 수 있다.
서버 : 키 보호, 사용자 인증, 지속적인 보호를 제공하는 것이 문제
클라이언트 : 키 보호, 사용자 인증, 지속적인 보호, 프로그램 자체에 대한 보안 문제가 존재한다. (해킹 가능)
- 동작 방법 : PDF 문서를 생성해 암호화 한 후 SDS에 전송. SDS는 지속적인 보호를 적용함. 타인이 이 문서를 요청해 서버에서 문서를 전달하게 됨. 키가 있어야 열 수 있는데, SDS 서버로 인증을 해서 인증될 경우에 키를 받는다. 키를 받아도 특정한 응용프로그램 (클라이언트)로만 pdf 문서를 열 수 있다.
- Code guard(Tamper-resistance를 위함)는 적용되지 않았다.
그리고 클라이언트 사이드에서의 오버뷰
바깥 층 Tamper-resistance (변조 저항) : 안티 디스 어셈블리, 그리고 안티 디버깅 등의 기법들. 뚫는 것을 지연시킨다.
안 쪽 Obfuscation(난독화) : 키 관리, 인증, 암호화, 스크램블링, ...
즉 콘텐츠에 대해서 혼돈(난독화?)를 먼저 적용하고 그다음에 조작방지를 적용하는 형태로 콘텐츠를 보호하게 된다.
혼돈은 공격자를 지연시킬 뿐 인내력 있는 사용자들은 공격자들은 결국에는 뚫을 수가 있다.
drm에 적용에 볼만한 다른 보안 기능
- 스크린 캡처 방지
- 워터 마킹
- 메타모피즘 (BOBE 방지)
정적인 데이터 말고 오디오나 비디오 같은 경우, 엔드포인트에서 스트림을 가로치는 중간자 공격이 발생할 수 있다. 또 재실행, 재배포 공격이 가능할 수 있다. 평문 캡처 공격도 가능할 수 있다. 막기 위한 방법으로 스크램블링 알고리즘이 있다. 암호화와 비슷한 형태로 사용된다. 협의를 기반으로 한다. 클라이언트가 저는 이런 암호화 메커니즘을 쓸 수가 있어요라고 하면 서버에서는 그중에서 하나 골라가지고 그거 가지고 콘텐츠를 암호화하는 방식을 사용하는 겁니다. 그래서 결국에는 이런negotiation을 기반으로 하고 있다. 포인트는 모든 클라이언트들이 조금씩 다른 집합을 가지고 있습니다. 클라이언트별로 조금씩 다른 암호화 집합을 가지고 있고 당연히 서버는 모든 집합을 알고리즘들을 다 알고 있어야겠죠.그래서 클라이언트별로 사용할 수 있는 알고리즘들이 다 리스트들이 다르고 서버는 모든 알고리즘들을 다 알고 있다. 그래서 중간에 처음에 이제 데이터를 주고받을 때 협의를 통해서 쓸 수 있는 알고리즘을 정해서 사용을 한다라고 이해를 하시면 되겠습니다. 데이터는 먼저 스크램블 돼서 서버에서 암호화가 되고요. 그리고 클라이언트에서 복호화되고 역스크램블 되고 이런 방식으로 동작을 수행을 하는 겁니다. 이런 방식을 우리가 디스크램블링이라고 합니다.
한 가지 포인트는 소위 말하는 이 스크램블링 알고리즘들이 각 클라이언트에 우리가 소위 말하면 구워져 있다고 합니다. 베이킹(bake in) 이 되어 있다고 해요. 디바이스 드라이브에 그냥 박혀 있는 거예요. 그래서 함부로 바꾸거나 변경을 할 수가 없다. 그리고 클라이언트별로 다 다른 형태의 리스트들이 베이킹 되어 있다라고 보시면 되겠습니다.
스크램블링의 장점
- 메타모피즘에 기반을 두고 있다. 변종화가 기본적으로 시스템 깊이 장착 되어있다.
- 역공학을 힘들게 한다.....??ㅠ?..최대한 콘텐츠를 지켜낼 수 있다.
- BOBE 방지
역시나 가장 위험한 건 역공학이네욘.. 이 방법 또한 은폐에 의한 보안이다. 알고리즘이 뭔지 모르게했다. drm은 소프트웨에서 보안을 유지하는 것에 대한 제약사항을 보여주는 가장 대표적인 예시이다.
Secure SW Development
- penetrate and patch (침략 후 패치) : 일단 내놓고 침해가 발생하면 대응한다. 시장 선점을 하기 위해 빨리 배포해야 하기 때문이다. 또한 기본적으로 안전한 소프트웨어를 개발하는 것이 어렵기 때문에, 사용자에게 일정 부분을 맡김..(버그 찾아오쇼...)
근데 침략 후 패치한다음 나중에 다 고치면 완전해지는거 아님? ㄴㄴ 아님. 패치할 때 새로운 결함이 추가될 수도 있음..
공개 소스가 안전할까 비공개 소스가 안전할까?
공개 소스의 경우 리눅스, 비공개의 경우 윈도우가 있다.
공개 소스
많은 사람들이 보기 때문에 결함이 감소할 것이다..! Kerkhoff 원칙의 변형이다.
- 근데 아무도 관심 없을 수 있음.
- 그리고 대부분의 사람이 전문가가 아닐텐디..
- 공격자도 결함을 같이 봄..
- 리눅스의 wu-ftp 도 10년동안 보안적 결함이 발견되지 않았는데 공개 소스 방식이 결함을 찾는데 유용할까..?ㅎ
비공개 소스
보안 결함 자체가 공격자한테 보이지 않음! 어떻게 보면 은폐에 의한 보안이라고 볼 수 있다.
- 공격자들은 소스코드 없어도 공격할 수 있다
공개와 비공개 소스에 대한 보안 관점에서는 둘 다 명확한 장점은 없다. 오히려 이런 공개냐 비공개냐가 중요한 게 아니라 결국에는 소프트웨어 개발 방식이 더 중요한 거지 소스가 오픈되어 있냐 안 되어 있느냐는 근본적으로 누가 더 낫다를 평가할 수는 없다. 그리고 둘 다 기본적으로는 침략 후 패치 모델을 따르고 있다.
Security and Testing
t개의 유닛을 가지고 있는 프로그램을 테스팅 할 경우 보안 실패의 확률은 E = K/t로 표현된다.
평균 실패 간격 (MTBF) = t/K 가 된다. t가 커질수록 평균 실패 간격이 넓어지게 된다. 즉, 테스팅이 많아질수록 보안성이 높아진다.
만약 MTBF가 100만시간이 되려면, 테스트도 100만 시간 정도 해야한다. 선형적으로 증가하는 관계기 때문에!
만약 공개 소프트웨어의 MTBF가 t/K고, 비공개 소프트웨어는 결함이 두배정도 발견이 힘들다고 하면 단순히 2(t/K)를 하면 될까?
ㄴㄴ. 여러가지 요인들을 고려해야한다.
비공개 소스는 일정 부분은 오픈 소스에 대한 알파 테스트를 수행하고 그리고 일정 부분은 비공개 소스 테스팅을 해서 뭔가 안전성을 높일 수가 있다!! -> 응 아님!! 그래도 공개소스와 큰 차이 업슴!
요약 : 공개랑 비공개 소스 간에 보안적인 차이점이 없다. 결함은 결국에는 선형적으로 발견이 된다. 테스팅 횟수에 따라서 보안성이 선형적으로 높아진다. 결함이 발견될 확률이 선형적으로 높아진다.
예시
MTBF = t/K이다.
한 소프트웨어에서 10의 6승의 보안 결함이 존재한다고 하자.
그리고 각 버그는 MTBF를 10의 9승으로 가진다.
공식에 집어 넣으면 10의 9승/ 10의 6승, 즉 결함 1개를 찾기 위한 테스팅 시간은 10의 3승, 1000시간이 된다.....
테스터들이 테스팅에 10의 7승 시간을 소요했다.
한 개 찾는데 10의 3승이므로, 테스터들은 총 10의 4승개의 버그를 찾았다.
10의 4승/10의 6승 * 100 = 1% 밖에 되지 않는다...........
10의 7승시간 소요해도 전체 버그의 1%밖에 찾지 못한다.
그러나 공격자는 딱 하나의 버그만 찾으면 된다. 즉 통계적으로도 공격자가 무조건 유리하다.
Secure Software Development
- 디자인을 처음부터 잘해야 된다잉.... ex) IPv4의 경우. 나중에 보완해서 IPv6을 냈지만 완전히 전환되지 못하고 있음..
- 프로토콜, 뷰, 가정과 같은 걸로 검증해서 보안 이슈들을 사용할 수 있다.
- 디자인 단계는 컨셉츄얼하기 떄문에 정형 방법들로 검증이 된다.
- 위험 분석. 위험분석은 요구사항, 구현, 테스팅 단계에서도 구현될 수 있다.
- 위험 리스트(list of what if)를 만들어서 수행한다.
- 슈나이저의 공격 트리를 통해서 분석할 수 있다. (루트에 가까운 공격을 예방할 수록 전체 공격을 방어할 수 있다.)
peer review (상호 검토)
- review (informal) - 친구에게 봐달라
- Walk-through (semi-informal) - 팀장님께 봐달라
- Inspection (formal) - 위원회에게 봐달라
Testing
어느 단위로 테스팅하느냐에 따라 나뉠 수 있다.
테스팅의 레벨
모듈 테스팅 - 코드의 작은 부분을 테스트
컴포넌트 테스팅 - 모듈의 조합을 유닛으로 테스팅
유닛 테스팅 - 컴포넌트 조합을 테스팅
통합 테스팅 - 전체 테스팅
테스트를 목적 기반으로 나눌 수 있다.
테스팅의 타입들
- 함수 테스팅
- 기능 테스팅 : 시스템 기능 테스트
- 인수 테스팅 : 실사용자가 직접 참여하는 형태
- 설치 테스팅 : 설치 시에 테스트
- 회귀 테스팅 : 어떤 변경이 이루어진 후에 테스트
Other testing issues
- 적극적인 결함 탐지 : 발견될때까지 기다리지 말고 결함이 발생할 거 같은 상황을 만든다.
- 결함 주입 : 테스팅할때 인풋으로 넣어본다
- 버그 주입 : 임의로 버그를 집어넣고 몇개의 버그가 찾아지는지 보고, 전체 버그의 수를 추정할 수 있다.
Testing 분석 결과
- 시스템 디자인 단계 : 17%
- 컴포넌트 디자인 19%
- 코드 인스펙션 15%
- 통합 테스팅 30%
- 시스템 리그레션 테스팅에서 16%
고르게 다 분석이 되고 결정적으로는 통합 테스팅에서 제일 많이 발견이 된다. 결국 다양한 종류의, 다양한 수준의 테스팅을 수행을 해야 된다. 그리고 최대한 오버래핑 테스팅을 수행을 해야 많이 찾아낼 수가 있다는 거죠.
비보안 테스팅: 시스템이 뭘 하기로 했는가 얘를 제대로 하는가 동작하는가를 찾음
보안 테스팅 : 시스템이 원래 무엇을 하기로 했는가를 검증을 하고 그리고 무엇을 하지 않게 되어 있는지, 계획된 것 이상으로 동작하지 않는지조차 검증.
Configuration
- 사소한 변화
- 어댑티브한 변화 - 플랫폼이 옮겨지는 등의 변화
- 완전한 변화 - 완전 갈아엎어지는 경우
등 매번 모든 변경은 새로운 보안적 결함을 발생시킬 수 있다라는 걸 명심해야 한다.
- 사후분석 (부검) 중요
- 시장 선점은 중요하다 (침략 후 패치)
- 소프트웨어에서 절대적인 보안은 불가능 하다. 인정하고 공격자로 하여금 딜레이 시키는것이 목적이다.
'ETC > 네트워크 보안' 카테고리의 다른 글
| 네트워크 보안 Ch.12 AI Security (0) | 2023.04.10 |
|---|---|
| 네트워크 보안 Ch.번외 (0) | 2023.04.10 |
| 네트워크 보안 Ch.10 Software Security (0) | 2023.04.10 |
| 네트워크 보안 Ch.9 Network Security (1) | 2023.04.10 |
| 네트워크 보안 Ch.8 Network Security (0) | 2023.04.10 |
