조금 전에 델마당과 뉴스 기사로부터 알게되었는데.. Delphi 4, 5, 6, 7 네 버전을 감염시키는 바이러스가 유행하고 있습니다.
개발SW로 전파되는 ‘피라미드 바이러스’ 발견
에스지어드밴텍, 델파이 개발자들 주의 당부
http://itnews.inews24.com/php/news_view.php?g_serial=436361&g_menu=020200
그리고 바이러스체이서의 개발사인 에스지어드밴택에서 자사 사이트에 올린 공지 내용.
http://www.viruschaser.com/main/customer/VCNotice_Dt.jsp?page=1&no=3448&vno=162¬iceType=A
사실 이 회사에서 발견한 것은 아니고 해외에서 먼저 발견된 것입니다.
http://www.delphipraxis.net/topic163041_virus+infects+delphi.html
제가 사용중인 세대의 PC들(사무실 PC, 집 PC, 노트북)을 살펴보니, 제 사무실 PC에도 감염되어 있더군요. 이 바이러스는 특별한 악의적 공격을 하거나 하지는 않지만, 감염된 델파이로 개발된 프로그램을 똑같이 감염시킵니다.
일단 감염여부 확인 방법과 치료 방법부터.
피씨의 Delphi 4, 5, 6, 7이 설치된 디렉토리에서 sysconst.bak 파일이 있는지 검사해서 있다면 감염된 것입니다. sysconst.bak 파일이 존재하는 경우, 즉 감염된 경우에는 원래의 원본 sysconst.dcu 파일이 확장자가 .bak으로 리네임된 것이고 sysconst.dcu 이름의 파일이 감염된 파일입니다. 따라서 sysconst.dcu 파일을 삭제한 후 sysconst.bak 파일의 확장자를 dcu로 변경해주기만 하면 됩니다.
지금 바로 확인들 해보세요. 또한, 이 시스템에서 감염된 후로 컴파일한 모든 프로그램이 똑같이 감염되므로, 모두 재컴파일해줘야 합니다. 물론 특별한 위해를 끼치지는 않기 때문에 그냥 놔둬도 큰일이 날 것은 아니지만.. 개발자로서 ‘내가 바이러스 프로그램을 배포했다’ 라는 느낌은 정말 찜찜하지 않겠습니까.
이제, 기술적으로 좀더 자세히 써보자면..
이 바이러스는 Delphi의 IDE 자체를 감염시키거나 하는 것이 아니라, Delphi 설치 디렉토리 밑의 dcu 파일 하나만을 감염시키는 것이구요. 이 방식을 구체적으로 살펴보면 일반적인 바이러스의 감염 방식과는 다른 꽤 재미있는 아이디어인데…
감염된 sysconst.dcu 파일을 Hex 에디터 등으로 들여다보면, 정상적인 길이 이후에 짤막한 Delphi 소스코드가 문자열로 들어가 있습니다. 이 소스 코드를 분석해보면 어떻게 동작하는지 나오는데요. 이 dcu 파일이 링크된 프로그램을 실행하면, Delphi 설치 디렉토리 아래의 sysconst.pas 소스 파일을 열어서, 자체 문자열 소스코드를 덧붙입니다. 그리고 Delphi 커맨드라인 컴파일러인 dcc32.exe를 실행해서 이 파일을 컴파일하죠. 그래서 이 바이러스 코드를 가진 새로운 dcu 파일이 다시 생성됩니다. 그리고 원본 pas 파일은 원래대로 해놓습니다.
그래서 이 환경에서 컴파일하면 감염된 dcu 파일이 링크되어 결과적으로 프로그램도 감염된 상태가 되고요. 이 감염된 프로그램이 실행되면 먼저 로컬 시스템에 Delphi 4~7 버전이 있는지를 검사해서, 존재하면 앞서와 똑같은 동작, 즉 감염된 sysconst.dcu 파일들을 만들어놓습니다.
물론, Delphi로 프로그램을 만들더라도 bpl들을 따로 배포하도록 하면 sysconst.dcu를 비롯한 표준 dcu 파일들을 링크하지 않고 bpl로부터 동적 링크하게 되므로 바이러스의 영향은 받지 않습니다. 하지만 대부분의 Delphi 개발자들이 bpl 동적 로딩 옵션을 끄고 단독 실행 파일을 만들고 있기 때문에..
이런 전후 상황을 보면, 전문적인 해커가 아니라 Delphi 개발자 한 사람이 번쩍 떠오른 아이디어를 장난스럽게 한번 구현해본 것 같습니다. 구현 방식이나 여러 면에서 정말 재미있기는 한데, 괜히 Delphi 자체에 문제가 있는 것처럼 비춰질까 좀 걱정스럽네요.
그럼, 왜 Delphi 4, 5, 6, 7 버전만 감염될까요. 3 이하 버전과 2005~2009 이상 버전들은 왜 감염되지 않을까요? 일단, 3 이하 버전에는 sysconst 유닛 자체가 없습니다. 4 버전부터 다른 유닛으로부터 sysconst 유닛이 분리되어 생겼죠. 또한, 이 감염 코드는 레지스트리에서 Delphi의 설치 여부와 설치 경로를 확인하는데, Delphi 7까지만 기존의 레지스트리 키 주소이고 2005부터는 Delphi 대신 BDS라는 이름의 키로 기록되기 때문에 감염되지 않는 것입니다.
그럼, 왜 sysconst를 선택했을까요. 이 바이러스의 방식이, 기존 델파이 기본 유닛들 중 하나의 소스 코드에 자신의 소스 코드를 덧붙이는 아이디어입니다. 따라서 기존에 코드가 많이 있는 pas 소스라면 개발자가 꽤 귀찮아질 겁니다. 반면, sysconst.pas는, 이름 그대로 상수 값들만 가진 유닛이기 때문에 선언만 잔뜩 있고 코드가 전혀 없습니다. 그래서 스트링으로 가지고 있는 자신의 소스를 쉽게 갖다 붙일 수가 있죠.
그럼, 이런 경우까지 다 감안해서 다시 만들면? 물론 조건을 더 추가해서 코드를 더 보강하면 Delphi 3 이하 버전과 2005 이상에도 감염되도록 만들 수 있습니다. 소스를 추가하고 dcc32 컴파일러로 직접 컴파일까지 해버리기 때문에요.
그렇다고 이런 위험이 Delphi에만 있을까요? 그것도 아니죠. Delphi의 dcu와 마찬가지로, C++ 개발툴의 경우에는 개발툴 자체에 소스와 함께 그 obj 혹은 lib 파일을 가지고 있는 경우가 대부분이죠. 그럼 똑같은 방식에 똑같이 당할 수 있습니다. 개발툴이기 때문에 중간 코드, 오브젝트 코드 파일을 가지고 있을 수밖에 없기 때문이죠. 뭐 닷넷이라고 안그럴까요? 닷넷이라고 해도 마찬가지 방식이 충분히 가능합니다. 내일 당장 VC++을 똑같은 방식으로 감염시키는 바이러스가 충분히 나올 수 있죠. (심심하면 나라도 만들어볼까나? ㅎㅎ)
깜빡하고 추가 감염을 막는 방법을 쓰지 않았네요.
이 바이러스는 sysconst.bak 파일이 존재할 경우 이미 감염되었다고 판단하고 더 진진행하지 않습니다. 따라서 임의의 sysconst.bak 파일을 만들어두면 감염되지 않을 겁니다.
하지만 만약 이 바이러스를 조금이라도 변형한다면 (특히 이 바이러스는 소스 자체가 들어있어서 누구나 보고 따라할 수 있기 때문에 더욱) bak 파일 존재 여부와 무관하게 계속 감염 시도를 할 수 있을 겁니다.
그래서 제안할 수 있는 더 확실한 방법은… sysconst.pas 소스 파일을 원래 디렉토리로부터 어딘가로 옮겨버리는 것입니다. 위 본문에서 설명한 것처럼, 이 감염 코드는 sysconst.pas 소스 파일에 코드를 추가한 후 직접 컴파일을 하기 때문에, 이 소스 파일이 존재하지 않으면 어떻게 해볼 방법이 없습니다. sysconst.pas 파일은 프로그램 컴파일에 아무런 관계가 없고 또 복잡한 VCL 소스 디렉토리들 중 어디에 있더라도 불러올 수 있으므로, 적당한 곳으로 옮겨버리면 사용하는 데에 불편함도 없고 바이러스 감염의 걱정도 없을 것입니다.
플러스* 이라는 이름의 국산 특정 검색어 서치 관련 Setup.exe 프로그램 내부에 델파이 개발 도구를 감염 대상으로 하는 Virus.Win32.Induc.a 바이러스가 감염된채 배포되고 있는 것이 발견되었네요. http://www.f-secure.com/weblog/archives/00001752.html 이 바이러스는 2009년 8월 15일부터 지속적으로 감염된 파일이 목격되고 있으며, 델파이 개발 환경을 통해서 감염되는 제한(직접적으로 다른..
2009년 8월 19일 Win32/Induc 바이러스가 발견되었습니다. 처음에는 그저그런 바이러스라고 생각했는데 감염 방식을 듣고 개념증명 형태로 생각했는데 각종 자료와 쏟아지는 샘플을 통해 델파이 제작자들에게 널리 퍼져있음을 알 수 있습니다. [관련자료] – Delphi 4~7을 감염시키는 바이러스 유행중 http://www.delmadang.com/community/bbs_view.asp?bbsNo=19&bbsCat=0&st=&keyword=&i..