Technical Memo (TM)

Live Update 시스템 보안 취약 사례 및 대응 사례

2011. 11.

- 1-

목차

1. 소개

2. Live Update 시스템 구성

3. Live Update 시스템 취약 사례 및 유형

4. 보안 Live Update 시스템 구현 사례

5. 결론

최종제출일 :

작성자 :

검토자 :

2011. 11.

금융보안연구원 u-금융연구팀 이재익 선임연구원

하우리 선행기술팀 최상명 책임연구원

SK커뮤니케이션 보안문화추진팀 차남경 대리

KT 보안혁신팀 한상흠 과장

소프트포럼 보안기술분석팀 박찬암 팀장

- 2-

＊ 본 연구보고서에서 검토한 연구 내용은 순수 연구 목적으로 작성되었습니다.

＊ 본 연구보고서 내용의 무단전재를 금하며, 가공 인용할 때에는 반드시『Live Update 시스템

보안 취약 사례 및 대응 사례』라고 밝혀 주시기 바랍니다.

＊ 본 연구보고서의 내용 중 오류가 발견되었거나, 내용에 대한 의견이 있을 경우 아래 연락처로

해당 내용을 보내 주시기 바랍니다.

금융보안연구원 정보보안본부 u-금융연구팀

이재익 선임연구원(duckgu@fsa.or.kr, 02-6919-9141)

- 3-

본 연구보고서는 “(가칭)u-금융 IT기술 연구회/보안 기술 실무 분과”에서 연구 되어진

연구 결과물임

1. 소 개

o 2009년 발생한 7.7 DDoS 사건을 비롯하여, 최근 3.4 DDoS사건․S社에서 대규모

개인정보 유출 사고 등 각종 보안 사고가 연이어 발생

o 악성코드 유포자가 제작된 악성코드를 대규모로 유포하기 위해 웹 하드 서비스

업체 시스템 및 공개 소프트웨어 업데이트 시스템을 해킹하여 다수의 이용자에게

악성코드를 유포하는 수법이 자주 등장하고 있음

o 이에 본 연구는 Live Update 시스템에서 발생된 보안 취약점 유형과 대응 사례를

살펴봄으로써, 서비스 사업자 또는 내부 시스템 관리자가 안전한 Live Update

시스템 구축·설계·운영에 기여코자 함

2. Live Update 시스템 구성

o Live Update 시스템의 구성은 비교적 간단한 구조로 설계 되어 운영되고 있음

< 그림 2 > Live Update 시스템 구성

- 단계1) 개발서버에서 업데이트 서버로 업데이트 파일 이관

- 단계2) 클라이언트가 사용하는 파일 버전 정보를 업데이트 서버로 전송

- 단계3) 클라이언트가 보내온 파일 버전 정보와 업데이트 서버에서 배포하는

파일 버전을 비교

- 4-

- 단계4) 클라이언트에서 보내온 파일 버전이 업데이트 서버에 있는 파일 버전

보다 낮으면 업데이트 파일을 전송하며, 그 반대의 경우 업데이트 미

실시

o 다만, Live Update 시스템 구성이 대부분 비슷할지라도 업데이트 파일의 무결성

또는 가용성 등을 보장받기 위한 암호 알고리즘 선택 및 시스템 설계에 있어 다양한

방법이 사용되어지고 있음

3. Live Update 시스템 취약 사례 및 유형

가. 일반 Live Update 시스템 보안 취약 사례

o 본 사례는 보안 요소가 포함되지 않은 Live Update 시스템에서 발생되었던

취약 사례로, 해당 요소의 동작 방식은 아래와 같음

- 단계1) 클라이언트가 사용하는 파일 버전 정보를 평문형태로 서버로 전송

- 단계2) 서버는 클라이언트가 보내온 버전 정보와 서버에서 배포하는 파일

버전과 비교

- 단계3) 클라이언트에서 보내온 파일 버전이 서버에 있는 파일 버전 보다 하

위 버전일 경우 업데이트를 실시

- 단계4) 클라이언트는 서버로부터 전송된 업데이트 파일 저장 및 실행

□ 취약 사례(#1)

o 사전에 악성코드를 배포할 수 있는 시스템을 가동 후, 클라이언트에서 업데이트

서버로 전송되는 파일 버전 정보를 서버에서 가지고 있는 버전보다 낮도록

버전 정보를 위·변조하여 파일을 강제 다운로드 받도록 유도＊

＊ 해커가 해킹을 하고자 하는 이용자와 동일 네트워크 영역에 위치하고 있을 조건

- 5-

o 업데이트 서버는 클라이언트에 전송한 파일 버전이 하위 버전임으로 업데이트

명령을 클라이언트로 전송

o 이때 접근하고자 하는 업데이트 서버 주소를 악성코드 배포 서버 주소로

위·변조하여 악성코드를 다운로드 받도록 유도

< 그림 3 > 업데이트 버전 정보 위·변조를 통한 악성코드 파일 다운로드

□ 취약 사례(#2)

o 업데이트 서버에 내재 되어 있는 보안 취약점을 이용하여 Live Update 시스템을

직접 해킹

o 업데이트 서버에서 배포중인 정상 다운로드 파일을 악성코드가 포함된 파일로

교체하고, 이를 배포할 수 있도록 파일 버전 정보를 위·변조

< 그림 4 > Live Update 시스템 공격에 의한 악성코드 파일 다운로드

- 6-

나. 내부 “PC 관리 업데이트 시스템” 보안 취약 사례

o 다수의 PC를 통합·관리하기 위해 사용되어지는 “PC 통합 관리 시스템”에서

제공하는 자동 업데이트 기능과 관련한 취약 사례로, 해당 시스템이 설계된

Live Update 시스템 흐름은 아래와 같음

- 단계1) 클라이언트가 사용하는 파일 버전 정보는 대칭키 암호알고리즘으로

암호화 실시

- 단계2) 서버는 클라이언트가 보내온 암호문을 복호화 한 후 복호화 된 정보

(버전 정보 등)를 서버에 있는 파일 버전과 비교

- 단계3) 클라이언트에서 보내온 파일 버전이 서버에 있는 파일 버전 보다 하위

버전일 경우 업데이트 실시

- 단계4) 전송되어질 파일을 대칭키 암호화 방식으로 암호화 한 후 암호문을

클라이언트로 전송

- 단계5) 전송되어진 암호문을 복호화 한 후 실행

□ 취약 사례

o 본 구성은 전송되어지는 정보(업데이트 파일 및 기타 정보)를 보호하기 위해

대칭키 암호화 방식을 이용하여 파일 버전 및 업데이트 파일 등을 암호화

하였음

o 해커는 클라이언트에 설치된 소프트웨어를 역공학(Reverse Engineering) 기술

등을 통해 암·복호키와 암호 알고리즘을 파악

o 전송되어지는 데이터에서 추출된 암·복호키로 데이터를 복호화 한 후, 데이터를

위·변조하고 하고 이를 다시 암·복호키로 암호화하여 전송하는 방법을 이용

- 7-

o 그 이후의 행동은 앞 절에서 설명 되어진 “일반적인 Update 업데이트 시스템

취약 사례”와 유사한 형식을 이용함

< 그림 5 > 대칭키 암·복호화 키 절취를 통한 악성코드

다. 웹 하드 서비스 및 OOO社 보안 취약 사례

□ 웹 하드 서비스 업체 취약 사례(#1)

o 최근 발생된 웹 하드 서비스를 통한 악성코드 배포는 Live Update 시스템 에

내제되어 있는 자체 취약점을 통한 해킹 보다는, 특정 관계자(사내관계자 등)의

이메일·게시물 등을 통해 내부 이용자를 감염시키는 방법을 이용

o 해커는 감염된 이용자를 통해 내부 시스템 정보를 습득 후, 습득된 정보를

이용한 특화된 공격을 감행하는 공격 기법을 사용

o 이러한 침해 공격 유형을 APT(Advanced Persistent Threat : 이하 APT)

공격이라 칭하며, 이는 특정 기업이나 조직을 노린 표적 공격의 대표 공격

유형임

- 8-

< 그림 6 > APT 공격 프로세스 (출처 : 시만텍)

o 수집된 내부 시스템 정보를 토대로 업데이트 서버에 접근, 악성코드를 업데이트

서버에 업로드 후 클라이언트가 이를 다운로드 하도록 업데이트 버전 정보를

위·변조

< 그림 7 > APT 공격을 통한 악성코드 다운로드

o 아래 그림은 2011년에 발생한 3.4 DDoS에 사용된 악성코드 개념도로써, 4개

웹 하드 업데이트 서버가 해킹된 후, 웹 하드 업체에서 제공하는 다운로더

(Downloader) 프로그램을 통해 악성코드가 배포되었음을 알 수 있음

- 9-

< 그림 8 > 3.4 DDoS 악성코드 유포 방법 (출처 : 안철수연구소)

□ OOO社 보안 취약 사례(#2)

o 본 사례는 OOO社 Live Update 시스템에 내제되어 있는 보안 취약점을 통한

악성코드 유포 사례로,

- 해당社에서 제공하는 Update 프로그램을 통해 유관 DLL 파일 및 EXE 등의

실행 파일을 업데이트 하는 과정에서 업데이트 다운로드 서버 경로가 변경

되었을 경우, 악의적인 파일이 다운로드 되고 이것이 실행되는 취약점을

악용한 내용임

o OOO社에서 운영하는 Live Update 시스템 방식은 아래와 같은 형태의 구조를

가진 업데이트 목록을 서버로부터 전송받게 됨

파일명 || 업데이트 파일 경로 || 설치경로 || 버전 || 파일에 대한 MD5 해시

o 그 이후 업데이트 파일 경로를 통해 해당 파일을 다운로드 하여 각 파일의

MD5 해시 값을 확인 후 업데이트 실시

o 본 구성 형태는 업데이트를 위한 구성 정보가 손쉽게 위·변조 할 수 있는,

즉 무결성과 기밀성이 보장되지 않은 취약한 구조로 운영되는 형태로, 당시

同 사례를 통해 거론되었던 보안 위협은 아래와 같음

- 10-

- 업데이트 파일 다운로드 경로에 대한 검증이 이루어지지 않음

- 업데이트 목록의 평문 형태 전송

- 배포 서버 검증 및 배포 파일 목록에 대한 무결성 검증 미흡

< 그림 9 > 000社 업데이트 취약 사례

라. 자동서명 처리시스템 보안 취약 사례

o 본 방식은 Live Update 시스템에서 업데이트 하고자 하는 파일을 공개키 기반

구조 방식을 이용한 배포 방식에 대한 취약 사례로, 해당 시스템이 설계된

Live Update 시스템 흐름은 아래와 같음

- 단계1) 업데이트 하고자 하는 파일을 “자동서명 처리시스템”으로 이관

- 단계2) “자동서명 처리시스템”으로 이관된 파일은 서버의 개인키로 자동 서

명되며, 서명된 파일은 Update 서버로 자동 이관

- 단계3) 암호화된 업데이트 파일은 클라이언트로 전송

- 단계4) 클라이언트는 서버의 공개키로 복호화 한 후 실행

- 11-

< 그림 10 > 자동서명 처리시스템 취약 사례

□ 취약 사례

o 본 구성은 현재 일반적으로 권고하는 안전한 파일 배포 방식이나, “자동서명

처리시스템”의 적절치 못한 보안성으로 인해 해커가 악성코드를 무단 배포

할 수 있는 취약 사례임

o 해커는 “자동서명 처리시스템”을 직·간접적으로 공격 후, 배포하고자 하는

악성코드를 “자동서명 처리시스템”으로 강제 이관하여 악성코드를 배포

o 그 이외 “자동서명 처리시스템” 뿐만 아닌, 잘못된 키 관리(다수의 개발자가

복수의 서버 키를 보유하는 등)로 부터 이와 유사한 해킹 위협이 발생할 수

있음

마. Live Update 시스템 취약 유형

o 앞에서 살펴본 취약 사례를 통해 아래와 같은 형태의 해킹 사례가 빈번하게

이루어짐을 알 수 있음

- Live Update 시스템의 직접적인 해킹

- APT 기법을 이용한 Live update 시스템 해킹

- 12-

- 보안이 고려되지 않은 Live Update 시스템 설계 및 운영

⦁ hosts 파일 위·변조를 통한 업데이트 서버 경로 및 파일 위·변조

< 그림 11 > 위·변조된 Hosts 파일 (출처 : 하우리)

⦁ ARP Spoofing 등을 통한 업데이트 서버 경로 및 파일 위·변조

< 그림 12 > ARP를 통한 데이터 위·변조 (출처 : KISA)

⦁ Live Update 자체 취약점을 이용한 악성코드 배포

4. 보안 Live Update 시스템 구현 사례

가. 공개키 기반 구조를 이용한 파일 배포

o 본 방식은 “공개키 기반 구조를 이용한 파일 전송 방법”으로 보안을 고려한

가장 일반적인 업데이트 방식이며, 이는 서버와 클라이언트와의 파일 전송 시

원치 않는 이용자에 의한 파일 위·변조 방지 효과가 있음

- 13-

⑤ 서버의 공개키로 전송되어진 파일의

전자서명 확인

⑥ 파일 비교

㉮ 전송 받은 파일을 서버에서

사용된 일방향 암호화와 동

일한 방식으로 해쉬값 추출

및 저장

㉯ 서버 공개키로 복호화된 해쉬값

저장과 “㉮”에서 추출·저장되어진

값을 비교

→ ex) example.exe| | ver(sing(pk, hash[A]))

※ ver : verification, pk : server’s public key

→ ex) example.exe = B

ex) compute hash[B]

< 그림 13 > 공개키 기반 구조를 이용한 일반적 파일 전송 방법

□ 업데이트 서버에서의 전자서명

① 전송하고자 하는 파일을 선택

② 전송하고자 하는 파일에 대한

일방향 해쉬 적용

※ MD5, SHA-1 등과 같은 해쉬 암

호 알고리즘 사용

③ 일방향 해쉬 값을 서버의 개인

키로 전자서명

④ 데이터 전송

→ ex) example.exe = A

→ ex) compute hash[A]

→ ex) compute sign(sk, hash[A] )

※ sign : signature, sk : server’s private key

→ ex) transmit example.exe| | sign(sk, hash[A])

□ 클라이언트에서의 전자서명 확인

- 14-

㉰ “㉮” 와 “㉯“의 값이 동일한

경우무결성이보장되었다고판단

⑦ 파일 저장 및 실행

→ ex) check hash[A] 〓〓 hash[B]

→ ex) execute example.exe

o 위와 같은 구조는 업데이트 파일에 대한 무결성 검증과 전자 서명＊을 통한

업데이트 서버에 대한 인증을 수행하는 기능을 동시에 갖추는 구조임

＊ exe, dll 파일 등과 같은 실행파일 자체에 대한 코드서명을 추가할 경우 향상된 보안성을

보장받을 수 있으나, 키 관리 방안이 고려되어야 함

< 그림 14 > 노출된 디지털 인증서를 이용한 악성코드(Stuxnet) 서명

o 본 방식으로 구현·구축 시 고려되어야 할 점은, 안전한 암호 알고리즘의 사용과

키 관리 방법 그리고 보안서버 구축에 대한 전반적인 보안 고려사항이 반영되어야 함

나. P2P 방식을 이용한 업데이트 파일 배포

o 본 방식은 파일 배포 시 P2P(Peer-to-Peer) 기술을 이용한 분산 파일 업데이트

방식으로 본 기술이 적용된 배경은 업데이트 서버의 부하를 줄이며, 악성코드

또는 기타 악의적인 목적에 의해 정상 업데이트를 방해하는 요소를 최소화 하는

등의 가용성 확보를 위해 적용된 기술임

o 구조는 이용자가 업데이트 서버로부터 최신 업데이트 파일을 다운로드 하면,

업데이트 서버에 접속한 이용자가 동일 네트워크 혹인 이종간 네트워크에서

최신 업데이트 파일을 검색 후 이를 업데이트 하는 방식을 사용

- 전송 파일에 대한 무결성은 공개키 기반을 이용한 파일 배포 방식을 사용

- 15-

- 본 배포방식은 안티바이러스 및 온라인게임 등에서 업데이트 파일을 배포하기

위해 널리 사용되고 있는 업데이트 방식임

< 그림 15 > P2P 방식을 이용한 파일 배포 방식

□ 장점

- 대용량 파일 전송에 적합하며 업데이트 서버의 부하를 줄일 수 있음

- 단편화된 파일을 여러 이용자에게 다운로드 받고 이를 조합하는 방식임으로

다운로드 속도가 증대 되는 효과가 있음

- 업데이트 서버에 장애가 발생하여도 일부 이용자가 최신 파일을 다운로드

하였을 경우, 그 이용자로 하여금 최신 파일로 업데이트가 가능함

□ 단점

- 이용자의 네트워크 환경에 의해 다운로드 속도의 보장이 어려움

- 크기가 작은 파일 또는 실시간으로 정보를 교환해야 하는 시스템의 경우에는

부적합할 수 있음

- 16-

구분 용도 내용

대칭키 암호화 암호화용

∙3-Key Triple-DES(128 bit)

∙AES(128 bit, 256 bit 권장)

∙SEED(128 bit)

∙ARIA(128 bit 이상)

공개키

암호알고리즘

전자서명

∙RSASSA-PSS(2,048 bit 이상)

∙RSASSA-PKCS#1(v1.5) (2,048 bit 이상)

∙ECDSA (224 bit 이상)

∙EC-KCDSA (224 bit 이상)

키교환 및 암호화용∙RSAES-OAEP (2,048 bit 이상)

∙ECDH (224 bit 이상)

해쉬 함수 무결성 검증

∙SHA-2

∙SHA-224

∙SHA-256

∙SHA-384

∙SHA-512

- AES-192/256 경우 이론적으로 가능한 공격이 발표되어 추후 안전성에 대한 변화 예상

- SEED-192/256이 발표된 상태임으로 안전성이 검증된 후 키 길이 변화 예상

< 표 1 > 권장 암호 알고리즘 종류 (출처 : 금융부문 암호기술 관리가이드 )

o 이에 사이즈가 큰 실행파일은 P2P 기술을 이용(N:N)하고, 실시간 정보가 필요한

파일의 경우 업데이트 서버와 직접 연결(1:N)하는 방식을 사용하는 사례도 있음

다. 안전한 암호 알고리즘 사용 및 키 관리 방법

o 공개키 기반 파일 배포를 이용한 파일 업데이트 기능 구현 시, 안전한 암호

알고리즘의 사용과 서버의 키 관리는 안전한 Live Update 시스템을 구성·운영

하기 위한 필수 요소임

□ 권장 암호 알고리즘 기술

o 다양한 암호 알고리즘 중 현재 권장되어지고 있는 암호 알고리즘은 아래 표와 같음

- 17-

o 이외 권장되는 암호 알고리즘을 선택하였을 경우, 아래와 같은 암호 키 길이

및 보안 강도가 유지되도록 권장함

대칭키

암호

알고리즘

(강도)

해쉬함수

(강도)

공개키 암호 알고리즘

암호 알고리즘

안전성 유지

기간인수분해

(bit)

이산대수 타원곡선

암호

(bit)공개키

(bit)

개인키

(bit)

112 112 2048 2048 224 224

2030년까지( 명기된 bit이상 적용 시2030년 이후)

< 표 2 > 권장 암호 알고리즘 구성 (출처 : 금융부문 암호기술 관리가이드 )

o 암호 알고리즘에 의해 생성된 블록 간의 연관성을 주는 방식인 운영모드는

ECB·CBC·CFB·OFB＊ 중 CBC 모드를 권장하나 데이터 길이에 제약이 있는

경우 CFB＊＊ 모드를 사용을 권장함

＊ECB 모드의 경우 보안관점에서 다른 모드에 비해 보안성이 낮으며, OFB 모드의 경우

암·복호화 방법이 동일하여 2번 암호화를 수행하는 경우 평문 유출 위협이 존재함

＊＊CFB 모드는 CBC 모드보다 보안성이 낮음으로, 추후 CFB 모드에서 CBC 모드를 사용

하도록 시스템 변경 노력 필요

□ 공개키 기반 구조에서의 키 관리 방법

o 보안 채널을 형성하는 주요 암호 키 중 서버 서명키의 유출은 데이터 위·변조에

사용 될 수 있는 원인이 될 수 있음으로 서버 키 관리를 위한 적정한 요구

사항이 요구됨

① 키 저장소 관리 요소

o 가용성 : 요청에 의해 언제든지 사용 가능한 형태로 보존 되어야 함으로

키 유효기간 동안 1개 이상, 최소한의 복사본이 만들어지고 별도의 안전한

장소에 보관되어져야 함

- 권장되는 별도 장소 예시

∙ 운영 시스템과 다른 시스템으로 또는 네트워크에서 단절된 시스템

∙ HSM 등과 같은 하드웨어 모듈 사용

- 18-

- 비 권장되는 별도 장소 예시

∙키 관리자 PC 또는 개발자 PC

o 무결성 : 키의 훼손 또는 위·변조로부터 안전하게 보호 되어야 함으로, 키

위·변조 및 도용·절취 등의 사고 발생 시 이를 즉시 탐지하고 대응할 수

있는 시스템 또는 대응 절차가 요구됨

- 물리적 보호 방법 예시

∙ 저장된 정보에 대한 접근을 차단하는 검증된 하드웨어적 암호화 모듈

또는 네트워크가 단절되어 있는 별도의 컴퓨터 시스템이나 장치

- 암호화적 보호 방법 예시

∙ 저장되어 있는 키가 변조되지 않았음을 확인하기 위해 메시지 인증

코드나 전자서명 값을 이용하는 방법

② 키 관리 단계별 관리 요소

o 안전한 키 관리를 위해 일반적으로 3단계 요소(운영준비단계/운영단계/폐기

단계)가 고려되어야 하며, 그 내용은 아래와 같음

(가) 운영 준비 단계

o 운영 시스템에 사용할 키를 준비하는 단계로, 아직 키가 생성되지 않

았거나 생성되어도 제 3의 기관으로부터 키에 대한 소유 증명을 받지

않은 단계

(나) 운영 단계

o 운영용 키가 시스템에 설치되어 사용하는 단계로, 전자서명이나 키

교환 기능을 위해 키가 사용하는 단계

o 이때 사용되는 키는 운영 준비 단계와는 다른 키를 사용해야 하며,

운영용 키는 반드시 키 관리자에 의해 키 쌍이 생성되고 백업되어야

하며, 그 사용에 있은 관리문서에 기록되어야 함

- 19-

(다) 폐기 단계

o 키가 외부에 노출되었거나 또는 유효기간 만료 되는 등 더 이상 시스템

에서 사용되지 않는 키를 폐기하는 단계

o 본 단계에서는 운영 준비 단계 또는 운영 단계에서 폐기 단계에 사용된

키로, 인증 받기 전 단계의 키 쌍, 인증된 키와 운영 단계에서 사용된

키 쌍, 인증된 키를 포함

o 암호 알고리즘 이용 가이드 및 안전한 보안 서버를 구축하기 위한 보안 가이드는

아래 사이트에서 제공 하고 있음

【 암호 부문 】

∙ 암호이용 안내서(2010.1, KISA)

∙ 암호 알고리즘 및 키 길이 이용 안내서(2010.1, KISA)

∙ 암호정책 수립 기준 안내서(2010.1, KISA)

(공통 : http://www.kisa.or.kr → 자료실 → 관련법령 → 안내서·해설서)

∙ 금융부문 암호기술 관리 가이드(2010.1, 금융보안연구원)

(http://www.fsa.or.kr → 자료마당 → 자료실 → 연구자료)

【 보안서버 부문 】

∙ 보안서버 구축 안내서(2009.12, KISA)

∙ 웹 서버 구축 보안점검 안내서(2010.1, KISA)

(공통 : http://www.kisa.or.kr → 자료실 → 관련법령 → 안내서·해설서)

5. 결론

o 2011년, 국내 대형 포털 서비스 및 금융사에서 대량의 개인정보 유출 및 대규모

업무 운영 서비스 장애 등 다양한 침해 사고가 발생하였음

o 과거 악성코드 유포자는 자신을 과시 하는 용도에서 지금은 특정 기업의 정보

수집 또는 인터넷 서비스 장애 유발 등 특정한 목적을 가진 악성코드가 지속적

으로 배포되고 있는 상황이며, 제작된 악성코드는 손쉽고 빠른 전파를 위해

Live Update 시스템을 직·간접적으로 공격하는 행위가 자주 발견되고 있음

- 20-

o Live Update 시스템은 이용자에게 기능이 향상된 프로그램 배포를 보다 신속하고

편리하게 이용하기 위해 널리 사용되어지고 있는 소프트웨어 배포 방식이나, 보안성이

고려되지 않을 경우 진화하는 다양한 해킹기법으로부터 Live Update 시스템의

순 기능이 퇴색되어 질 수 있음

o 앞서 Live Update 시스템에 대한 대표적인 취약 사례와 보안성 향상을 위한

Live Update 시스템 설계 사례 등을 살펴봄으로써 Live Update 시스템이 갖추어져야

할 기본적인 보안 사항을 살펴보았음＊

＊ 본보고서에는제시된설계사례는운영시스템및서비스에대한환경적요소가고려되지않음을밝힘

o 안전한 Live Update 시스템 운영 및 제공을 위해서는 서비스 환경에 부합하는

적절한 구성 설계와 적절한 암호 알고리즘 선택, 그리고 이에 대한 주기적인 모니터링

및 관리체계 수립·활동 등이 무엇보다 중요함

o 이를 위해 향후로 추가로 연구되어질 사항으로는 Live Update 시스템 설계 및

구현에 있어 특화된 보안성 평가 방법론 및 안전한 암호화 알고리즘 사용에 대한

홍보 그리고 안전한 시스템 운영을 위한 보안 서버 구성·모니터링 체계 구축·운영·

관리 방법 등의 연구가 필요할 것으로 판단됨

- 21-

□ 참고 문헌

[1] 금융부문 암호기술 관리가이드(금융보안연구원), 2010.1

[2] 암호이용 가이드(KISA), 2007.12

[3] 3.3 DDoS 공격 분석 보고서(하우리), 2011.3

[4] 암호이용 안내서(KISA), 2010.1

[5] 암호 알고리즘 및 키 길이 이용 안내서(KISA), 2010.1

[6] 암호정책 수립 기준 안내서(KISA), 2010.1

[7] 웹 서버 구축 보안점검 안내서(KISA), 2010.1

[8] ARP Spoofing 기법을 이용한 웹 페이지 악성코드 삽입사례(KISA), 2007.12

[9] 비밀키를 이용한 토큰 업데이트 보안 인증 기법, 2007.2

[10] 웹하드 서비스를 통해 생성된 Botnet을 이용한 DDoS 공격 피해사례(KISA), 2009.12

[11] 서버 기반 배포를 위한 서버 구성 방법(Microsoft), 2010.2

[12] 정보보안 제품들에 대한 무결성 검증 도구 설계 및 구현, 2002.1

[13] 공개키 기반 구조를 이용한 소프트웨어 저작권 보호, 2002.9

[14] 보안서버구축 안내서(KISA), 2009.12

[15] 디지털 컨텐츠 배포를 위한 보안 체계에 관한 연구, 2003.2

[16] Live Update Administrator’s Guide(symantec), 2005

[17] SK 커뮤니케이션즈 해킹 관련 상세 분석 보고서(하우리), 2011.8

[18] 하우리, http://www.hauri.co.kr

[19] 안철수연구소, http://www.ahnlab.co.kr

[20] 한국정보보호진흥원, http://www.kisa.or.kr

[21] 금융보안연구원, http://www.fsa.or.kr