데이즈

안녕하세요? 허니입니다. 취약한 게시판 소프트웨어 사용에 따른 구성에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

공개 및 상용 게시판 Editor 중 특정 취약점이 존재하는 애플리케이션 사용으로 인하여 파일 업로드, 디렉토리 노출, 파일 다운로드 등과 같은 취약점이 발견될 수 있다. 게시판 Editor 설치 후 Sample 파일 및 Default 설정으로 인한 취약점으로 인가되지 않은 사용자로부터 악의적으로 사용될 수 있다.

 대응방안
서버 및 홈페이지에 설치된 모듈 등의 환경 설정과 기본 파일에 대하여 노출 되는지 확인해야 한다. 게시판 Editor 설치 시 기본으로 제공되는 기본 폴더를 삭제 하여 일반 사용자의 접근을 막아야 한다.

안녕하세요? 허니입니다. 공개소프트웨어 사용에 따른 보안 구성에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

윈도우 서버 컴퓨터에서 기본으로 설치되는 원격관리기능인 WebDA, 무료 배포 게시판 제작프로그램 테크노트, 제로보드 같은 오픈소스로 만들어진 웹사이트나 기본적으로 제동되는 프로그램들 경우 공개된 소프트웨어 이기에 소스정보를 획득하기가 쉽고 취약점을 찾기 쉽기 때문에 공격자가 보다 쉽게 정보를 획득하고 공격하기 쉽다. 

 대응방안
WebDAV와 같은 원격관리기능의 설정은 중지시키고 무료 배포 게시판 제작 프로그램의 경우는 해당 제작사 홈페이지에 업데이트 되는 패치를 항상 최신 버전으로 갱신해야 한다.

안녕하세요? 허니입니다. 불필요한 주석에 의한 정보 노출 취약점에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

개발자는 복잡하고 정확한 동작 구현을 위하여 작은 단위의 테스트 코드를 작성하여 실행하여 보거나 자세한 주석을 작성하여 기입하면서 구현을 한다. 테스트한 로직 및 중요한 정보에 대한 주석에 대한 처리 미흡으로 서버 컴파일에서 제거 되거나 일반 사용자에게 노출 되면 안 되는 정보들이 노출 되어 공격자에게 중요한 정보를 제공하게 되는 가능성이 있다.

 대응방법

클라이언트에서 구현되는 HTML등의 소스는 사용자에게 공개되어 있는 것과 동일하므로 중요한 로직 및 주석에 대한 처리는 웹 서버에서 구현되는 언어와 같이 처리되도록 작성하여야 한다.

안녕하세요? 허니입니다. SQL Injection 취약점에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

고의적으로 예외 오류메세지를 발생시켜 공격에 필요한 정보 획득에 악의적으로 사용될 수 있다. 때문에 웹 서버 상에서 발생하는 오류 메시지를 적절히 처리하는 설정이 반드시 필요하다.

 일반적인 대응방법
원하지 않은 정보가 유출되는 것을 막기 위하여 표준 예외 처리 아키텍처를 포함 하여 개발 해야 합니다. 자세한 오류 처리를 제한하거나 기능을 비활성화 해야 하며, 경로 정보와 디버그 정보를 출력 하지 않아야 합니다. 기본 에러 처리기를 우선시 하여 항상 “200” 에러 화면을 반환하게 함으로써 자동화된 스캐닝 도구가 심각한 에러의 발생 여부를 결정하는 능력을 감소 시켜야 합니다. 모든 에러(404, 403, 500 error) 발생 시 에러 메시지는 사내에서 지정된 사용자 정의 에러페이지로 Redirect 시켜 에러 페이지에 DBMS 쿼리 정보나 소스의 오류에 해당 하는 코드가 노출되지 않도록 합니다. 공격자로부터 자세한 정보를 숨기기 위하여 모든 트랜잭션들에 대한 불규칙한 대기 시간을 부여 해야 합니다. 사용자에게 에러 메시지를 보여주기 보다는 서버의 에러 로그로 남기도록 설정해야 합니다.

 웹서버별 대응방법
- 보안설정(IIS)

- 보안설정(Apache)

 
- ServerTokens 지시자를 선택

- php.ini 설정

- 보안설정(Tomcat)
{tomcat_home}/conf/web.xml 파일에 아래와 같이 추가하여 에러코드에 따른 포워딩 페이지를 설정해야 합니다.

- 보안설정(Weblogic)
weblogic.properties 파일에 아래와 같이 추가하여 에러코드에 따른 포워딩 페이지를 설정해야 한다.

안녕하세요? 허니입니다. 디렉터리 목록 노출 취약점에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

WAS의 환경 설정 미흡으로 웹 디렉터리 호출 시 해당 WAS의 디렉터리 목록이 외부에 노출되는 취약점입니다. 인터넷 사용자에게 모든 디렉토리 및 파일 목록이 노출되고, 파일의 열람 및 저장도 가능하게 되어 비공개 자료가 유출될 위험이 있습니다.

 일반적인 대응방법
서버의 설정을 변경하여 기본 페이지가 없을 경우 Directory 목록이 노출되지 않도록 해야 합니다.

 웹서버별 대응방법
- 보안설정(IIS)
윈도우 웹 서버의 경우 [제어판] > [관리도구] > [인터넷 서비스 관리자](혹은[인터넷 정보서비스]) 메뉴에서 [기본 웹 사이트]의 마우스 오른쪽 클릭 > [속성] > [기본 웹 사이트 등록 정보] > [홈 디렉토리] > [디렉토리 검색] 체크를 해제합니다.

[그림 2] 디렉토리 검색불가 설정

- 보안설정(Apache)
아파치 웹 서버의 경우 httpd.conf 파일내용 중 Options 항목 뒤에 Indexes 단어를 삭제한 후 웹 서버 데몬을 재구동

[그림 3] httpd.conf 파일내용

[그림 4] Indexes 설정 삭제

안녕하세요? 허니입니다. Command Injection 취약점에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

Command Injection은 시스템 명령어를 호출하는 어플리케이션의 인자 값을 조작하여 의도하지 않은 시스템 명령어를 실행시키는 공격 기법입니다. 이는 웹 어플리케이션이 많이 발전하지 못했던 시절에 특정 데이터를 처리하기 위해서 시스템 명령어를 웹 어플리케이션에서 호출하여 사용하던 것으로 인해서 자주 발생합니다.

  위협
- Command Injection을 이용하면 웹 어플리케이션을 구동하고 있는 시스템 계정의 Shell 권한을 획득하는 것으로 볼 수 있어 시스템에 존재하는 다양하고 유익한 명령어들을 이용해서 시스템에 악성 스크립트나 파일들을 업 로드 할 수 있습니다. 만약 대상 시스템에 시스템적인 취약점이 존재한다면 공격자는 시스템 관리자 권한까지 획득이 가능합니다.

- 현재는 Java나 ASP, PHP등의 어플리케이션에서 이전의 시스템 명령어를 호출하여 처리하던 파일/디렉터리 핸들링이나 타 어플리케이션 호출 등의 기능들을 구현하고 있기 때문에 현저하게 줄어든 추세입니다. 하지만 개발자의 편의나 어플리케이션의 특성으로 인해서 여전히 사용되고 있는 곳이 있습니다. Command Injection에 취약한 CGI로 Perl이 자주 언급되는데 이는 시스템에 자주 접근하는 Perl 언어의 특성상 발생하는 경우입니다. 어플리케이션 별로 Command Injection에 취약한 함수들은 다음과 같습니다.

  취약성 판단
- Command Injection의 예제로 자동화된 공격 코드 생성으로 인해서 문제가 되었던 Santy 웜을 들 수 있습니다. phpBB2.0.10의 viewtopic.php의 경우 preg_replace()를 사용하고 있는데 이를 통해서 공격자는 SQL Injection 공격과 Command Injection 공격을 수행할 수 있습니다.

‘%2527’은 urldecode와 magic quotes의 작용으로 인해서 ‘%25’가 퍼센트로 변환되고 ‘%27’이 다시 단일 인용 부호(‘)로 변환됩니다. 이를 통해서 취약한 함수를 사용하고 있는 highlight 인자에 주입하여 어플리케이션의 정상적인 작동을 중단시키고 system() 함수를 이용해서 악의적인 시스템 명령어를 실행할 수 있게 됩니다. 이러한 취약점을 이용해서 Santy 웜이라는 자동화 공격 도구가 제작되었고, 동일한 취약점을 이용하지만 그 패턴은 지속적으로 변화되었다. Santy 웜 A형의 경우 다음과 같은 패턴을 가지고 있습니다.

 대응방법
- Command Injection 공격은 그 첫 번째가 취약한 함수를 사용함으로 인해서 발생된다고 할 수 있습니다. 개발 단계에서 특별한 사유가 아니라면 앞서 언급한 함수들의 사용은 회피하는 것이 바람직합니다. 만약 반드시 사용해야 하는 것이라면 입력 값을 검증하는 필터에 파이프(|), 앰퍼샌드(&), 세미콜론(;) 등 시스템상에서 멀티라인을 지원하는 특수 문자에 대한 검증을 실시하여 해당 함수에 유해한 값이 전달되지 못하도록 해야 합니다. 다음의 예제와 같이 미리 정의된 인자값의 배열을 만들어 놓은 후 외부의 입력에 따라 적절한 인자값을 선택하도록 하여 외부의 부적절한 입력이 명령어로 사용될 가능성을 배제하여야 합니다.

안녕하세요? 허니입니다. 패스워드 정책 유무 및 반영 여부에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

사용자는 웹 어플리케이션의 가장 큰 구성 요소이며, 보안 측면에서도 중요한 부분을 갖고 있습니다. 실제로 웹 어플리케이션 보안의 대부분이 사용자를 보호하고 프라이버시 정보를 지키는데 있다고 해도 과언이 아니다. 대부분의 웹 어플리케이션이 이러한 위협에 노출되어 있으며, 정책이 필요합니다.

대응방법
1. 사용자 인증 구현: 강력한 패스워드 사용 권장
-  패스워드 필드에 입력 값은 다양한 변수로 구성되어야 하고, 입력 값에 대한 확인이 필요
-  패스워드의 복잡성을 요구하도록 구성하고 정규 함수로 구현

2. 공격자라 사용자에 대한 많은 정보를 갖고 있다면, 패스워드를 추측하여 계정에 대한 인증을 받을 수 있습니다. 그 후에는 패스워드와 개인정보를 변경하여 사용자로 가정할 수 있습니다.

3. 간단한 사용자 인증을 구현하지 않음

4. 임시 패스워드는 최대한 짧은 기간 동안 사용하게 하며, 사용자가 패스워드를 변경하게 유도합니다.

5. 대부분의 웹 해킹 기법은 취약한 패스워드 구조를 통해 이루어진다. 패스워드 추측 도구를 포함하여 웹과 관련된 공격 도구는 각종 사이트에 많이 노출되어 있는 실정입니다.

6. 인증 정보 수집
- URL의 쿼리 문자열에 사용자 이름이 지정되지 않게 합니다.
- 사용자 디렉터리를 생성해서는 안되며, 다른 방법을 통해 사용자 이름을 획득할 수 없어야 합니다.
- 사용자 이름이나 계정 ID를 추측할 수 있게 허용해서는 안 된다. 예를 들어 Email 계정 자체를 사용한다던가 평범한 단어를 사용하는 것입니다
- 어떤 사용자가 인터넷뱅킹을 이용하기 위해 다음의 사이트에 로그인을 했다고 가정하면, http://xxx.com/userid=1010&account=test
- 이 계정에서 볼 수 있듯이 몇 개의 변수는 그 의미를 추측하기 충분합니다. 그러므로 다음과 같이 변경해 보기로 합니다.

http://www.xxx.com/userid=2000&account=test
http://www.xxx.com/userid=1&account=test

- 이 결과 다른 사람의 정보를 볼 수 있게 됩니다. 이러한 간단한 가정이 응용된다면, 더욱 큰 사건을 유추하기 충분할 것입니다.

7. 강력한 패스워드

- 패스워드 및 인증과 관련된 생체 정보는 복호되지 않도록 일방향 암호화하여 저장합니다.
- 모든 암호화 코드를 중앙으로 집중시켜 알고리즘이나 키를 쉽게 변경 시킬 수 있게 합니다

8. 패스워드 수명과 패스워드 이력

9. 사용자 인증 후에 패스워드의 수명을 항상 점검하고 관리합니다.
- 오랫동안 사용하지 않은 계정은 정보 유출 및 해커의 표적이 될 수 있습니다. 따라서, 웹 개발자는 다음과 같은 형태로 오랫동안 서비스를 이용하지 않은 사용자 계정을 중지시키는 프로세스를 갖고 있어야 합니다.

10. 패스워드 변경
- 패스워드 변경은 사용자 페이지에서만 동작하고 한 단계씩 변경하도록 합니다.
- 사용자가 자신의 패스워드를 변경한 후에는 즉시 모든 세션이 닫히고 새로운 인증을 받아야 합니다. 충분한 시간만 있다면 패스워드 추측 공격이나 시스템의 취약성을 이용한 공격 코드를 통해 공격자는 패스워드를 발견할 수 있습니다. 그러므로, 우리가 할 수 있는 가장 최선의 방법은 주기적으로 패스워드를 변경하는 것입니다.

11. 잊어버린 패스워드 재설정
- 패스워드 재설정: 잊어버린 패스워드를 찾는 과정에 대한 이벤트는 클라이언트 IP주소와 함께 자세하게 기록되어야 합니다.
- Email을 통한 정보 전송: 중요한 정보를 Email을 통해서 전송해서는 안 된다. 가능하면, PGP나 S/MIME과 같은 디지털 서명이나 암호화 통신을 사용하게끔 합니다. 많은 웹 사이트에서 패스워드를 잊어버린 사용자를 위해 Email을 통해 그들의 패스워드를 전송합니다. 그러나 이러한 기능이 제대로 구현되지 않았다면, 위험한 상황에 빠질 수 있다.
- 임시 패스워드 할당: 임시 패스워드를 생성해야 한다면, 강력한 랜덤 알고리즘을 사용해야 합니다. 임시 패스워드에 의존하지 않게 시스템을 구현해야 합니다. 그렇지 않으면, 강력한 패스워드를 갖고 있거나 임시 패스워드를 받는 즉시 변경하게끔 해야 합니다. 대부분의 시스템에서 이에 대한 기간이 느긋한 편입니다. 따라서 패스워드에 대한 재설정을 로그인 즉시 수행토록 하는 것이 중요합니다.
- 비밀 질문 사용: 사용자 자신만의 질문을 통해 패스워드 추측을 시도하지 못하도록 합니다. 또한, 많은 사람들이 공통으로 대답할 만한 질문을 사용하지 않는다. 비밀 질문을 사용하여 패스워드를 찾는 과정을 효과적으로 구현하기 위해 가장 중요한 사항은 사용자의 개인적인 프라이버시 입력 없이 패스워드 재설정을 실행하지 않는 것입니다. 더욱 효과적인 방법은 다양하게 몇 단계로 비밀 질문을 추가하는 것입니다. 대부분의 사용자는 안전하지 않은 질문을 선택하기 때문에 사용자에게 비밀 질문을 선택하는 것을 피해야 합니다. 예를 들어, “태어난 곳은?”, “당신의 전화번호는?”, “당신의 생일은?”과 같은 질문입니다..

안녕하세요? 허니입니다. 취약한 계정 및 Default 계정 사용 취약점에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

계정과 동일한 패스워드 생성 또는 단순 패스워드가 생성 가능하도록 웹 로직이 구현되어 있을 경우 취약한 사용자 계정 사용으로 인해 타인의 개인정보가 노출될 수 있으며, 테스트 용도로 사용된 계정 또한 삭제되지 않을 경우 WAS에 침해사고가 발생될 수 있습니다.

  대응방법
계정 접속에 대한 임계 값 설정으로 권한이 없는 사용자의 무차별 대입 공격을 차단합니다. 일반적으로 알려진 영문 및 추측하기 쉬운 패스워드가 아닌 영문, 숫자 포함 8자리 이상 및 회사 내규에 따른 패스워드 설정을 해야 합니다.

[참고] 패스워드 생성 보안로직 권고사항

자주 사용하거나 유추하기 쉬운 패스워드를 별도의 파일로 관리하여 패스워드 생성 시 파일(취약한 패스워드 리스트)과 비교한 뒤 해당사항이 없을 경우에만 패스워드 생성될 수 있도록 코딩한 예제입니다.(JAVA)

안녕하세요? 허니입니다. 인증 정보 취약한 코딩에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

사용자 정보에 대한 암호화 시 HTML 혹은 Base64 등 일반 사용자가 쉽게 디코딩 할 수 있는 인코딩 방식을 사용하여 사용자 개인정보 및 계정정보 암호화 시 쉽게 디코딩 되어 사용자 정보가 노출될 수 있는 취약점입니다. 중요정보를 암호화 하기 위해 사용되는 방법이 인코딩(또는 암호화)를 하는데 취약한 인코딩 방법(예:base65) 및 암호화 알고리즘(예:RC2, RC4, RC6, MD4, MD5, SHA1, DES등)을 사용할 경우, 공격자가 해독이 가능하여 중요정보가 노출될 수 있습니다.

 대응방법
사용자 개인정보 및 중요정보는 SSL 등 암호화 방식을 통해 데이터 전송을 해야 하며, 사용자 인증에 따른 쿠키 사용 시 사용자 정보 및 계정, 패스워드는 쿠키에 사용하지 말아야 합니다. 개인정보 등 중요정보를 보호하기 위해 사용하는 암호알고리즘 [참고] 적용 시, IT보안인증 사무국이 안전성을 확인한 검증필 암호모듈을 사용한다.

[참고] 패스워드 생성 보안로직 권고사항

안전하다고 알려진 암호화 알고리즘(SEED)를 사용하여 암호화 진행할 경우 다음과 같이 진행합니다.(JAVA)

안녕하세요? 허니입니다. 사용자 브라우저 인증 취약점에 대해서 알아보고 대응 방법에 대해 알아보도록 하겠습니다. 사이버 해킹에 대해 공부하시는 학생이나 연구원 분이 계시면 도움이 될 것이라 생각합니다.

사용자의 개인 정보 또는 작성한 정보는 해당 사용자만 수정이 가능해야 하나 인증 미흡으로 인해 타 사용자가 접근하여 열람, 수정이 가능한 취약점입니다. 인증우회 가능성은 프록시 툴을 이용하여 인증절차를 분석하고 인증 결과값을 클라이언트가 조작하여 인증을 우회하는 방법입니다. 이는 타 사용자의 개인정보 열람, 아이디 도용, 타 사용자 작성 정보의 비 인가된 수정 등이 가능합니다.

 대응방법
회원 가입 시 적절한 권한이 필요한 페이지는 항상 세션 및 쿠키 등으로 현재의 사용자의 권한을 확인하여 접근을 제한해야 합니다. 세션인증 외에 입력 비밀번호로 인증할 경우, 인증이 필요한 페이지 내에 인증체크 모듈을 포함시켜 인증 결과값이 클라이언트를 거치지 않고 서버 내에서 인증 성공 여부에 따라 접근통제가 완료되도록 구현해야 합니다. DB 및 기타 데이터의 조회, 수정, 삭제 페이지에 인증체크 모듈을 포함시키고 클라이언트를 거쳐 온 인증 결과값을 신뢰해서는 안되며 인증 결과를 클라이언트로 전송하지 않도록 해야 합니다.