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

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

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

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

크롬의 자동완성 기능

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

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

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

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

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

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

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

단계별로 따라가 보자.

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

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

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

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

비밀번호에 들어간다.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. icmp ping

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

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

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

위의 예는 특정 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 패킷을 보낼 수 있다. 분명히 말해두지만 그런 행위는 범법행위다.

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

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

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

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

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

#hping3

요즘 택배사를 사칭하는 문자메시지를 보내 스마트폰에 악성코드가 포함된 앱의 설치를 유도하는 스미싱이 유행하고 있다. 스미싱이란 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 파일을 수동으로 다운로드 받고 설치하라고 하는 경우는 무조건.. 해킹이다.!!! 라고 생각하고 근처에 얼씬도 하지 말아야 한다.

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의 개인정보라이프사이클 및 법적 요구사항에 대해 더 깊이 있게 살펴봐야 하기 때문에 조금은 더 까다로운 심사가 될 듯 하다.

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

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

내부관리계획 수립

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

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

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

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

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

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

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

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

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

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

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

※ [별표]의 유형1 - 정보주체 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 실습페이지

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의 키 생성 과정을 설명해본다. 하지만 디피헬만보다 훨씬 어렵다. 수학에 소질이 있다면 이해가 쉬울 수도 있다. 

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

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

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

RSA의 암호화와 복호화

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

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

RSA의 예제

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

그저 신기할 따름이다. 

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

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

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

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

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

안전하게 웹 해킹을 공부할 수 있는 방법이 있다.  직접 웹해킹을 공부할 수 있도록 실습환경을 구축하는 것이다. 몇몇 실습환경 구축에 사용되는 웹소스가 제공되는데 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가 "안전한 공인인증서"로 인정하지 않을 뿐이다. 

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

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

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

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

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

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

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

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

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

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

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

위의 제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와 비밀번호 인증만 수행하는 경우가 많다. 심지어 누군가 입사하게 되면 서버 접속을 위한 게이트웨이에 인사시스템과 연동하여 무조건 계정이 생성되고 부서 혹은 업무에 따라 접근 권한을 신청할 경우 접속할 서버의 목록을 보여주고 있어 서버에 접근하는 업무를 하지 않는 임직원이 서버 접근을 위한 게이트웨이 장비에 계정을 갖고 있는 경우가 많다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

정보보안 관련 인증심사를 진행할 때 가장 어려운 점은 바로 심사 대상 기관의 정보자산에 대한 정보의 부족이다.  내가 참여한 인증심사는 평균적으로 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 링크를 클릭할 경우 에러페이지로 연결되도록 수정한 것으로 확인 되었다.

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

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

악성코드들이 대부분 그렇듯 랜섬웨어도 계속 진화한다. 창과 방패의 싸움과 너무도 흡사하다. 하지만 기본 컨셉은 바뀌지 않는다. 감염된 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.do

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

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

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

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

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

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

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

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

먼저 인터넷에서 다운로드 받은 zip 파일을 압축 해제하면 MP3 파일만 담긴 새로운 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개월 이상 장기적인 관점에서 매입할 가상화폐를 정하고 조금 오르거나 조금 내리는 그래프에 흔들리지 말고 기다리는 것이 가장 좋은 투자법이라 여겨진다.

개인정보를 취급하는 많은 기업과 공공기관들은 항상 망분리 이슈에 시달리게 됩니다. 하지만 망분리를 누가 왜 해야하는지를 정확하게 이해하고 있는 기업이나 공공기관도 있는 반면 정확하게 이해하고 있지 못한 기업이나 공공기관도 있습니다. 사실 조금만 관심을 갖고 법령을 찾아보면 되는데 특별히 보안에 관심이 있는 사람이 아니면 그냥 해야한다더라 정도로 이해하고 있는 경우가 많습니다. 그리고 정보보안기사나 ISMS인증심사원, PIMS 혹은 PIA 자격 시험을 준비한다면 관련 법령을 꼼꼼히 알고 있는게 좋습니다.

개인정보의 보호와 관련된 법률은 정보통신망 이용촉진 및 정보보호 등에 관한 법률(이하 정보통신망법)과 개인정보보호법이 대표적입니다. 그 중에서 망분리와 관련된 조항을 갖고 있는 것은 정보통신망법 입니다. 개인정보보호법과 하위 규정에는 명시적으로 망분리에 관한 조항은 존재하지 않습니다. 다만 "내부망"이 물리적 망분리, 접근 통제시스템 등에 의해 인터넷 구간에서의 접근이 통제 또는 차단되는 구간임을 명시하고 내부망과 인터넷 망에 개인정보를 저장할 때 암호화 필요성을 언급하고 있을 뿐입니다.

정보통신망법의 망분리 관련 조항

망분리는 정보통신망법에서 언급되는데... 사실 정보통신망법 본문조항에서는 직접적으로 언급되지 않습니다. 다만 제28조에서 개인정보보호를 위한 관리적·기술적 보호조치에 대해 다음과 같이 언급하고 있습니다.

대통령령으로 정하는 기술적·관리적 보호조치에 "망분리"에 대한 내용이 언급되어 있겠죠? 그럼 대통령령을 들여다 보겠습니다. 

대통령령 제27951호(2017.3.22) 정보통신망 이용촉진 및 정보보호 등에 관한 법률 시행령 제15조(개인정보보호 조치)입니다.

위에서 제②항 3호에서 "개인정보처리시스템에 접속하는 개인정보취급자 컴퓨터 등에 대한 외부 인터넷망 차단" 조치를 취할 것을 규정하고 있습니다. 이 조항이 바로 숱하게 많은 "망분리" 이슈를 만든 조항입니다. 그리고 제⑥항에서 상세한 보호조치의 내용을 방송통신위원회에서 정하여 고시하도록 규정하고 있습니다. 

그렇다면 해당 고시를 찾아봐야 합니다. 보다 상세한 망분리에 대한 언급이 있을테니까요. 그 고시는 바로 방송통신위원회고시 2015-3호(2015.5.19) 개인정보의 기술적·관리적 보호조치 기준 입니다. 이 고시의 제2조(정의)를 보면 정보통신망법에서의 망분리에 대한 정의가 명시되어 있습니다.

간단하게 말에 개인정보처리시스템에 접속하는 업무망과 인터넷망을 분리하라는 것이죠. 하지만 이 정의만으로는 정확하게 무엇을 어떻게 하라는 것인지 조금 부족합니다. 조금 더 자세한 규정은 제4조(접근통제)에 명시되어 있습니다.

제⑥항에서 망분리 의무 대상을 규정하고 있습니다. 이용자수 100만명(전년도 말 기준 직전 3개월간 일일평균)이거나 정보통신서비스 부문 매출액 100억원 이상인 정보통신서비스 제공자가 대상입니다. 그리고 대상 기관(기업)의 개인정보처리시스템에서 개인정보를 다운로드 또는 파기할 수 있거나 접근권한을 설정할 수 있는 개인정보취급자의 컴퓨터가 망분리 대상임을 확실하게 규정하고 있습니다. 또한 망분리의 방법은 물리적 또는 논리적이라고 규정하고 있습니다.

하지만 아쉽게도 물리적 망분리와 논리적 망분리에 대한 상세한 설명은 없습니다. 알아서 하라는 것일까요? 맞습니다. 알아서 해야합니다. 하지만 주입식 교육에 찌든 대한민국의 어른들은 알아서 하라고 하면 참 힘들어 하고 자신의 생각과 다르게 망분리를 수행하면 싸웁니다.  ^^ 그래서 한국인터넷진흥원에서는 "개인정보의 기술적·관리적 보호조치 기준 해설서"를 만들어서 배포하고 있습니다. 참 친절하죠? ^^ 그 해설서에서는 망분리에 대해 다음과 같이 해설해주고 있습니다.

망분리

이 이상의 해석은 스스로 알아서 하시길 바랍니다. ^^

일을 하다보면 이따금씩 패킷을 캡쳐하고 내용을 확인해야할 때가 있습니다. 가장 대표적인 경우가 로그인 페이지 및 개인정보 입력/수정 등의 페이지가 암호화 통신을 하는지 확인해야할 때 입니다. 

웹브라우저로 확인할 때는 HTTPS 등 암호화 통신 프로토콜이 적용되어 있는지만 봐도 암호화 전송 여부를 알 수 있지만 모바일 앱, 특히나 모바일 웹 페이지가 아닌 바이너리로 개발되어 있을 때는 암호화 통신 여부를 쉽게 확인하기가 어렵습니다.  결국 모바일 앱의 통신 패킷을 캡쳐하여 .pcap 파일로 저장한 뒤 PC로 불러오고 와이어샤크 등의 패킷 분석 도구로 패킷을 열어봐야 합니다.

그 과정을 포스팅 합니다.

안드로이드에서 실행되는 앱의 통신 패킷 캡처하기

사례는 모바일 웹으로 들겠습니다. 실제로는 모바일 앱이나 웹 모두 관계 없습니다. 앱을 실행시켜 로그인 창까지 열어 놓습니다.

안드로이드의 경우 홈버튼을 눌러 홈으로 간 뒤 tPacketCapture와 같은 안드로이드 용 패킷 스니핑 앱을 실행시킵니다. 이 앱을 먼저 설치하고 실행시켜 두어도 무방합니다. tPacketCapture의 경우 루팅없이 동작하는 앱입니다.

tPacketCapture의 경우 실행 후 MAIN 탭으로 이동하면 아래 화면과 같이 CAPTURE 버튼이 보입니다. CAPTURE 버튼을 누르면 패킷스니핑이 시작되고 캡쳐된 패킷은 .pcap 파일로 저장되기 시작합니다.

CAPTURE 버튼이 RUNNING 버튼으로 바뀌고 Current File: 항목에 패킷이 캡쳐되어 저장되는 파일이 보입니다. 이 상태에서 이전에 실행해 둔 앱의 로그인 화면으로 갑니다. 작업관리자를 이용해도 되고 앱 전환 버튼을 눌러 이동해도 됩니다.

로그인 화면에서 아이디와 비밀번호를 입력하고 로그인을 합니다.

제가 즐겨 들어가는 뽐뿌라는 커뮤니티의 경우 로그인을 완료하면 아래 화면처럼 초기화면이 보입니다. 이 상태가 되면 tPacketCapture 앱에서 로그인 시 전송된 아이디와 패스워드가 캡쳐되었을 겁니다. 암호화가 되었다면 패킷을 열어봐도 아이디와 패스워드가 보이지 않을 것이고 암호화가 되지 않았다면 아이디와 비밀번호가 그대로 노출되어 보일 것입니다.

이제 tPacketCapture에서 스니핑을 중단해야 합니다. 아래 화면처럼 화면 상단을 쓸어내려 알림창을 열고 적색 상자에 보이는 tPacketCapture 활성화 이벤트를 터치합니다.

다음에 나타나는 tPacketCapture 창에서 "연결 끊기"를 선택합니다.