보안에 대한 생각 - 파일 해시 검증하기

 최근에 filezilla server를 다운로드 받기 위해서 filezilla의 웹사이트로부터 다운로드 링크를 클릭하고 깜짝 놀랐습니다. filezilla 의 다운로드 링크는 souceforge로 연결되어 있고 자동으로 다운로드가 시작되는 형태로 제공되는데 다운로드에 사용한 Chrome에서 위험성을 경고하며 차단했기 때문입니다. 사실 위험성을 경고하고 계속 진행할 수 있는 형태의 알림이었다면 신경안쓰고 계속진행했을지도 모르겠습니다. 아니 계속 진행했겠지요. 하지만 계속 진행이 불가능했기 때문에 Internet Explorer를 이용하여 다시 다운로드를 시도했습니다. 그런데 Internet Explorer에서도 안전하지 않다는 경고와 함께 다운로드가 차단되는 것이 아닙니까?

Chrome 차단 스크린샷

※화면상에 Chrome이용자의 경우 블럭 당할 수 있으므로 다른브라우저로 다시 시도해달라고 씌어져있다.

Internet Explorer 차단 스크린샷

 위와같이 시도한 브라우저 두개다 차단당하고보니 무언가 문제가 있는지 생각하고 원인을 찾아보니 SourceForge를 이용해서 다운로드를 진행할 경우 해당 소프트웨어의 인스톨러가 직접 다운로드 되는 형식이 아닌 SourceForge용 인스톨러로 랩핑(Wrapping)된 형태의 인스톨러가 다운로드 된다는 사실을 알 수 있었습니다.

 스크린샷 위쪽이 별도로 검색해서 다운로드 받은 파일이고 아래쪽이 SourceForge에서 받은 파일입니다. 파일 아이콘은 물론 용량에도 차이가 있습니다.

※유감스럽게도 FireFox에서는 차단없이 다운로드가 되었습니다.

 차단당하는 파일을 실행해 볼 용기(?)는 없어 실제로 실행해보지는 못했지만 랩핑 되어있는 파일이 용량이 적은걸로 보아 실행시에 다운받아서 설치하는 하는듯 보였고, 이 설치 과정에서 보안에 취약할만한 무엇인가가 의도하지 않게 추가적으로 설치되는게 아닌가 하는 생각이 들었습니다.

 위와 같은 상황을 겪고보니 그동안 보안에 대해서 인식하고 대처하고 있다고 생각했었지만 습관적으로 SourceForge와 같이 알려진 사이트들은 안전하다고 안일하게 생각해 온게 아닌가 하는 생각이 들었습니다. 사실 국내의 인터넷 환경 자체도 ActiveX등의 설치를 강요받고 있기에 예를 누르도록 훈련되어 있는지도 모르겠습니다만 이런 안일함이 헛점을 만들고내고 있었습니다.

 아무튼 FileZilla는 다운로드 받아야 했으므로 별도의 다운로드 링크를 통해서 다운로드 받았습니다. 그동안은 SourceForge라는 신뢰성(?)있는 사이트를 통해서 다운로드 받아서 신경쓰지 않았지만 다운로드 받은 파일의 검증을 해야할 필요가 있었습니다. 이럴때 사용할 수 있는 것이 파일의 해시값을 이용한 CheckSum 검증입니다. 해시라는 것은 일종의 패턴이라고 보시면 될 듯 합니다. 대상이 되는 데이터(여기서는 파일)로 부터 일정한 공식(혹은 함수)에 의해 산출된 값을 의미하는데 같은 파일을 이용하면 항상 같은 결과 값이 산출되므로 많은 오픈 소스들이 파일을 검증하는 방법으로 채택하고 있습니다. 해시값을 구해서 검증하는 것 자체는 단순히 다운로드 받은 파일이 받으려고 했던 파일이 맞는 것인지 검증하는 것 뿐이지만 이런 검증을 거치므로서 보안위협을 배제할 수 있습니다.

FileZilla 해시코드

 FileZilla의 경우 위의 스크린샷 처럼 여러번 클릭해서 확인할 수 있었습니다만 일반적으로는 해당 파일의 다운로드 링크와 함께 확인할 수 있는 경우가 대부분 입니다. 해당 파일의 해시값을 확인했으면 실제 다운로드 받은 값으로부터 해시값을 산출하여 확인한 해시값과 비교하여 검증해야 합니다. 그러면 해시값을 산출하는 방법에 대해서 알아보도록 합시다.

Windows fciv 커맨드

C:\>fciv -add 파일명 -both

 Windows플랫폼의 경우 빌트인(built-in)커맨드는 존재하지 않지만 별도로 제공하는 fciv커맨드(File Checksum Intergrity Verifier)를 이용하여 이용하여 검증할 수 있는데 아쉽게도 위에서 다운로드 받은 FileZilla 인스톨러의 경우 Sha512 해시값만 제공하고 있는데 fciv커맨드의 경우 md5, sha1 해시만 지원하므로 사용할 수 없었다.

※fciv는 윈도우 사이트에서 다운받을 수 있습니다.

온라인 해시 변환 사이트

 OS의 빌트인 커맨드를 이용하는 방법이 가장 간단하고 안전하지만 위처럼 아쉽지만 지원하지 않는 경우에는 다른 방법을 이용하는 수밖에 없습니다. 이경우 선택할 수 있는 방법으로 온라인 해시 변환 사이트입니다. 검색 사이트 등에서 파일, 해시 등으로 검색하면 다양한 사이트를 찾을 수 있습니다.

 위의 스크린샷은 검색으로 찾은 사이트(http://hash.online-convert.com/sha512-generator) 중 하나를 골라서 해시값을 산출한 결과 화면이다. 물론 해당 사이트가 과연 신뢰할 수 있는가에 대한 의문이 생길 수 있을 듯 합니다. 위처럼 다운로드 사이트와 검증 사이트가 다를 경우 불특정 다수의 조작된 파일과 해시값을 동시에 가지고 있어야 하므로 현실적으로 어렵다고 할 수 있습니다. 하지만 100%안전하다고 할 수 없으므로 서버에서 사용할 프로그램등과 같이 리스크 대비 큰 피해가 예상되는 경우에는 사용을 자제하라고 말씀드리고 싶습니다. 개인적인 용도에서는 피해대비 이익이 적으므로 괜찮지 않을까 생각됩니다.

※본 포스팅의 예제처럼 오픈소스등과 같이 공개적인 파일의 검증에만 사용하시기 바랍니다. 절대 기밀성이 필요한 파일을 알 수 없는 사이트에 업로드하지 마십시오.

※본 포스팅에서는 보안의 관점에서 해시값 검증을 이용한다고 언급되어있지만 보안적인 부분 이외에도 전송오류를 잡아내기 위한 용도로도 사용할 수 있습니다.

프로그래밍

  다음으로 소개할 방법은 프로그래밍 언어를 이용하는 방법이다. 다룰 수 있는 언어가 있다면 간단한 프로그램을 이용하여 해시값은 산출할 수 있습니다. 아래는 Java를 이용하여 파일의 해시값을 산출하는 예제 입니다.

public String getFileHash(final String algorithm, final File target)
			throws NoSuchAlgorithmException, IOException {

	final MessageDigest md = MessageDigest.getInstance(algorithm);
	InputStream is = null;
	try {
		is = new FileInputStream(target);
		byte[] buffer = new byte[1024];
		int readBytes = 0;

		while ((readBytes = is.read(buffer)) > -1) {
			md.update(buffer, 0, readBytes);
		}

		StringBuilder builder = new StringBuilder();
		byte[] digest = md.digest();
		for (byte b : digest) {
			builder.append(Integer.toHexString(0xff & b));
		}
		return builder.toString();
	} finally {
		if (is != null) {
			try {
				is.close();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}
	}
}
//실행예
getFileHash("SHA-512", new File("D:/FileZilla_Server-0_9_49.exe"));

리눅스(Linux) 플랫폼

 리눅스 플랫폼의 경우는 다양한 빌트인 커맨드를 제공하므로 따로 준비해서 이용할 필요는 없습니다. 윈도우 이용하는 분들도 별도로 리눅스 서버가 존재한다면 업로드하여 검증을 진행하면 편리할 듯 합니다.

#md5sum
#sha1sum
#sha224sum
#sha256sum
#sha384sum
#sha512sum

 사실 해시를 이용한 파일 checksum 검증은 주로 오픈소스의 경우에 제공되는 경우가 많습니다. 그 이유는 오픈소스의 경우 재정적인 문제로 자체적으로 다운로드를 제공하기가 어렵기 때문에 여러 기관의 협조등에 의해서 다운로드를 제공하는 경우가 많고 다양한 미러링이 제공되는 경우가 많아 다운로드를 통제할 수 없기 때문입니다. 이러한 보안 취약점을 보완하기 위해서 자체 다운로드에서 다운받지 않은 경우 해시를 이용한 검증을 통해서 보안 취약점을 배제할 수 있습니다.

 여러분도 다운로드 받은 파일의 출처가 의심스럽다면 한번 검증해 보는건 어떨까요?