RedScreen

안녕하세요 Message입니다.

오늘의 포스팅 주제는, 예전에 마주쳤을때 당황했었던 해시뱅(HashBang, #!)에 대해 다루고자 합니다.

해시뱅에 대해 개념부터 장단점, 개인의 의견이 잘 포스팅되어 있는 블로그가 있습니다.

https://blog.outsider.ne.kr/698  : 해시뱅(#!)에 대해서... 

하지만 저는 개발자가 아니므로.. 해시뱅을 다뤄본 경험이 없기 때문에

초보 분석가가 해시뱅을 바라보는 시각에서 포스팅을 진행했습니다.

처음 해시뱅을 맞딱뜨렸을때는 무엇으로 검색해야 할지 몰라서 헤메었습니다.

Commit your way to the LORD, trust in him and he will do this. [PSALms 37:5]

안녕하세요. Message입니다.

Webhacking.kr Lv8 문제풀이입니다. 

------------------------------------------------------------------------------------------------------------------------------------------

1. 문제분석

------------------------------------------------------------------------------------------------------------------------------------------

문제 메인에 접속하면 아래와 같은 문구가 뜹니다.

새로고침을 누르니 카운트가 늘어납니다.

최대치인 70번까지가 시도할 수 있는 횟수인걸까요?

소스코드를 살펴보니 "<!-- index.phps -->" 힌트가 있습니다.

해당 페이지에 접속하면 아래와 같은 소스코드가 나타납니다.

------------------------------------------------------------------------------------------------------------------------------------------

2. 문제풀이

------------------------------------------------------------------------------------------------------------------------------------------

1) 문제 의도파악

소스코드를 살펴보면 아래부분에

"select id from lv0 where agent='$_SERVEr[HTTP_USER_AGENT]'" 쿼리문의 결과로

"admin" 값이 얻어지면 $solve() 함수가 호출됨을 알 수 있습니다.

2) 장애물

우리가 원하는 "admin" 값이 나오려면 여러가지 방법이 있습니다.

가장 빨리 생각난건 지난 문제의 해결방법이었던 union을 이용하는 방법입니다.

하지만 이번 문제에서는 preg_match() 함수를 이용하여

"union"을 비롯한 "char, ascii" 등의 문자는 물론, 여러가지 특수문자를 모두 필터링하고 있습니다.

3) 이용할것

처음에는 DB를 검색하는 Select 문을 조작해서 어딘가에 있을 "admin" 값을 찾아와야 하나? 싶었습니다.

하지만 그런 방법은 맨땅에 헤딩하는 느낌이 들더군요. "admin"값이 없을수도 있죠.

결국 직접 "admin" 값을 입력해야 한다는 생각이 들었고 union, char 등을 이용한 공격을 시도해보았지만,

시도하면 할수록 필터링이 잘되있다는 깨달음만 얻었지요.

이런 방법이 아닌가 싶다가 PHP 소스 아랫부분을 살펴보니, INSERT문이 보입니다.

위의 쿼리문에 대한 결과가 "admin"이 아닐경우, guest의 접속 여부를 기록하기 위한 쿼리로 보입니다.

$ip 변수를 조작하기 보다는, 버프를 이용하여 $agent 값을 변경해야겠다는 생각이 듭니다.

또한 결정적으로 따옴표가 치환되는 부분은 $agent 변수가 아니라 $_SERVER[HTTP_USER_AGENT] 기 때문에

$agent를 변경해도 문제를 클리어할 수 있습니다.

4) 공격시도

지난 문제에서 연습한대로 APMSETUP에서 테스트를 수행합니다.

수행하기에 앞서 아래와 같은 절차대로 간단히 필드2개 짜리 테이블을 생성하고 쿼리문을 날려봅니다.

처음에는 PHP 소스코드 형식에 맞추기 위해 다음과 같이 쿼리문을 날렸습니다 → message', 'admin')";#

나름대로 아래의 PHP소스상에서 주석처리와 쌍따옴표까지 고려를 한것이죠.

하지만 아래와 같이 쿼리문 에러와 함께 DB에서도 오류가 나더군요. 형식이 맞지 않습니다.

쌍따옴표는 PHP소스코드 상에서 문자열을 표시하기 위해 사용된 부분이군요.

이래서 직접 DB에 테스트 하지 않으면, 어떤 오류가 나는지도 모르고 헤메는 경우가 많은듯 합니다.

따라서 다음과 같이 수정하여 쿼리문을 날립니다(쌍따옴표 제거) → message', 'admin');#

APM 환경에서는 성공적으로 질의문이 수행됩니다.

실제 문제풀이 사이트에 접속합니다.

버프슈트를 이용하여 User-Agent에 테스트 완료된 문자열을 입력해줍니다.

인자수를 맞추어 줘야 하기 때문에, 의미없는 루프백 주소를 추가해서 총 3개의 인자를 넣어줍니다.

→ message','127.0.0.1','admin');#

이후에 User-Agent를 message 로 조정해서 쿼리를 날리면

"admin" 값을 가져오면서 성공입니다!

By Red_Message.

Chapter 04 웹 보안

Section 01 웹에 대한 이해

- 웹은 처음에는 단순히 대학 내 각 연구실 사이의 데이터 전송을 위해, 하나의 시스템과 다른 하나의 시스템 간의 통신을 위한 프로토콜을 만들어 사용했다.

- 그러다 점차 프로토콜이 하나둘씩 늘어 결국 시스템을 만드는 회사마다 서로 다른 통신 프로토콜을 사용하게 된 것이다.

- 개별 시스템 산의 통신에는 큰 문제가 없었으나 다른 회사의 제품들과 서로 통실할 수 없다는 문제점이 발생

- 이를 해결하기 위해 하나의 프로토콜을 해석한 후 다른 프로토콜로 바꾸어 다른 시스템으로 전송해주는 장치인 게이트웨이(Gateway)를 개발했다.

- 게이트웨이가 나온 후에야 원격의 두 지점 간의 통신이 가능해졌고, 비로소 네트워크라고 부를 만한 것이 생겼다.

- 1969년 미 국방부 산하 고등연구 계획국 ARPA(Advanced Research Projects Agency)에 의해 전 세계 주요 거점을 연결하는 네트워크가 처음 만들어졌다.

- 이 네트워크를 알파넷이라 부르며, 흔히 알파넷을 인터넷의 시작이라고 한다.

- 1970년대의 네트워크는 TCP/IP 프토로콜로 연결되고 일반에 공개됨에 따라 크게 발전하기 시작

- 우리나라의 경우 1994년 한국통신이 카이스트와 연구기관 등에 학술 교융/정보 교류용으로 제공한 '하나망'을 일반에 공개하고 코넷(KORNET)을 시작함으로써 인터넷에 첫 발은 내딛게 되었다.

- '웹'의 정식 명칭은 월드 와이드 웹(WWW : World Wide Web)이다.

- 세계 규모의 거미집 또는 거미집 모양의 망이라는 뜻으로, 1989년 스위스 제네바에 있는 유럽 원자핵 공동 연구도(CERN)에서 근무하던 팀 버너스 리(Tim Berners Lee)에 의해 연구 목적의 프로젝트로 시작

- 프로젝트의 목적은 전 세계에 흩어져 있는 종업원 및 연구자와 연구 결과나 아이디어를 공유할 수 있는 방법을 모색하는 것이었다.

- 처음 프로젝트를 계획할 당시에는 웹을 'Hyper Text Project'라고 불렀는데, 이는 1960년대에 테드 넬슨이 만든 신조어로 다른 문서와 연관 관계를 가지는 텍스트를 의미하는 것이다.

- 현재 웹 문서로 가장 흔히 쓰이는 HTML(Hyper Text Markup Language)은 이 Hyper Text를 효과적으로 전달하기 위한 스크립트 언어이다.

- 웹에 접근하기 위해서는 웹 브라우저가 필요하다. 최근에는 대부분 마이크로소프트의 인터넷 익스플로어를 사용하지만, NCSA에서 개발한 모자이크(Mosaic)나 넷스케이프에서 개발한 넷스케이프 네비게이터(Netscape Navigator) 등도 있다.

Section 02 HTTP에 대한 이해

- 웹에서는 FTP, Telnet, HTTP,  SMTP, POP 등 여러 프로토콜이 쓰인다. 그중 가장 흔히 사용되는 프로토콜이 HTTP이다.

- HTTP를 이용하면 사용자는 다양한 응용 프로그램에 접근하여 텍스트/그래픽/애니메이션을 보거나 사운드를 재생할 수 있다.

- HTTP는 웹 처리 전반에 걸쳐 토대가 되기 때문에 웹 서버를 HTTP서버라고 부르기도 한다.

- 웹 서버에는 웹 서비스를 구현하기 위한 웹 언어가 존재하며, 그 종류는 HTML, ASP, JSP, Java Script 등이 있다.

1. HTTP 프로토콜

- HTTP는 0.9 버전부터 사용되었다.

- 0.9 버전은 서버로부터의 단순 읽기 기능만 지원한다.

- HTTP 0.9는 하나의 웹 페이지 안에서도 텍스트와 그림마다 Connect 과정을 반복해서 거쳐야 했기 때문에 무척 비효율적이었고 오래 사용되지 못했다.

- 하지만 1.0 버전부터는 한 번의 Connect 후에 Request와 Response를 반복할 수 있게 되었다.

2. HTTP Request

- HTTP Reauest는 웹 서버에 데이터를 요청하거나 전송할 때 보내는 패킷으로, 주로 GET, POST와 같은 메소드를 사용한다.

가. GET 방식

- 가장 일반적인 HTTP Reauest 형태로 웹 브라우저에 다음과 같은 요청 데이터에 대한 인수를 URL(Uniform Resource Locator)을 통해 전송한다.

www.wishfree.or.kr/list.php?page=1&search=test

- GET 방식에서는 각 이름과 값을 &로 결합하며 글자 수를 255자로 제한한다.

- 데이터가 주소 입력란에 표시되기 때문에, 최소한의 보안도 유지되지 않는, 보안에 매우 취약한 방식이다.

- 간혹 아이디나 패스워드가 인수로 저장되러 전달되는 경우도 발생한다.

나. POST 방식

- URL에 요청 데이터를 기록하지 않고 HTTP 헤더에 데이터를 전송하기 때문에 GET 방식에서의 '?page=1&search=test' 와 같은 부분이 존재하지 않는다.

- 내부의 구분자가 각 파라미터(이름과 값)를 구분하며, 서버가 각 구분자에 대한 내용을 해석하여 데이터를 처리하기 때문에 GET 방식에 비해 상대적으로 처리 속도가 늦다.

- 인수 값을 URL을 통해 전송하지 않기 때문에 다른 이가 링크를 통해 해당 페이지를 볼 수 없다.

- 게시판 등에서 파일 업로드는 POST 방식으로만 할 수 있는데, GET 방식과는 달리 보내려는 데이터가 URL을 통해서 노출되지 않기 때문에 최소한의 보안성은 갖추고 있다.

다. 기타 방식

① HEAD 방식 : 서버 측의 데이터를 검색하고 요청하는데 사용한다.

② OPTIONS 방식 : 자원에 따라 요구/응답 관계에서 관련된 선택 사항의 정보를 요청할 때 사용된다. 이를 통해 클라이언트는 어느 것을 선택할지 결정할 수 있고, 자원과 관련 필요 사항도 결정할 수 있다. 서버의 수행 능력도 알아볼 수 있다.

③ PUT 방식 : 메시지에 포함되어 있는 데이터를 지정한 URI(Uniform Resource Identifier) 장소에 그 이름으로 저정한다.

④ DELETE 방식 : URI에 지정되어 있는 자원을 서버에서 지울 수 있게 한다.

⑤ TRACE 방식 : 요구 메시지의 최종 수신처까지의 루프백 검사용으로 쓰인다. 클라이언트가 보내는 요구 메시지가 거쳐가는 프록시나 게이트웨이의 중간 경로 및 최종 수신 서버까지 이르는 경로를 알아내는데 사용된다.

3. HTTP Response

- 클라이언트의 HTTP Request에 대한 응답 패킷이다.

- 서버에서 쓰이고 있는 프로토콜 버전, Request에 대한 실행 결과 코드 및 간략한 실행 결과 설명문(OK 등)의 내용이 담겨있다.

- 전달할 데이터의 형식과 데이터 길이 등과 같은 추가 정보가 MIME 형식으로 표현되어 있는데, 헤더 정보 귀에는 실제 데이터(HTML이나 그림)가 전달되며 데이터 전달이 끝나면 서버는 연결을 끊는다.

- HTTP Response의 주요 실행 결과 코드

Section 03 웹 서비스에 대한 이해

- 웹 서비스는 웹 언어를 통해 제공된다.

- 정적인 서비스 제공 언어 : HTML, 자바 스크립트, 비주얼 베이직 스크립트 등

- 동적인 서비스 제공 언어 : ASP, JSP, PHP 등

1. HTML

- HTML(Hyper Text Markup Language)은 가장 단순한 형태의 웹 언어이다.

- 웹 서버에 HTML 문서를 저장하고 있다가 클라이언트가 특정 HTML페이지를 요청하면 해당 HTML 문서를 클라이언트로 전송한다.

- 그러면 클라이언트는 이 웹 페이지를 해석하여 웹 브라우저에 표현해 주는데 이런 웹 페이지를 정적인(Static) 웹 페이지라고 한다.

- 정적인 웹 페이지는 고객의 취향이나 변화에 적응할 수 없고 새로운 것을 추가하는데 많은 시간이 걸린다는 단점이 있지만 보안에는 장점이 많다.

- 웹 해킹은 웹 브라우저와 웹 서버 사이에 전달되는 값들의 변조를 통해 웹 서버의 설정이나 로직을 바꾸는데, 정적인 웹 페이지는 '바쑬수 있는 가능성'이 매우 낮다.

2. SSS

- 사용자들은 점차적으로 웹 페이지가 각기 다른 요구에 따라 능동적으로 변하기를 기대했다.

- 동적인(Dynamic) 웹 페이지를 제공할 수 있는 PHP(Personal Home Page), ASP(Active Server Page), JSP)Java Script Pages)와 같은 언어를 개발했다.

- 동적인 페이지를 제공하는 스크립트를 SSS(Server Side Script)라 한다.

- 동적인 웹 페이지에서는 스크립트에 HTML 확장자 대신 ASP 또는 JSP 의 확장자를 가진 웹 문서를 요청한다.

- ASP의 경우 DLL이나 OCX 같은 파일을 이용하고 JSP의 경우 서블릿을 이용해 요청을 처리한다.

- 그리고 결과를 HTML 파일로 만들어 클라이언트에 전송해준다.

- ASP를 이용하기 위해서는 윈도우 기반의 IIS 웹 서버를 설치해야 하지만 JSP는 어떤 운영체제에서도 동작한다.

3. CSS

- 서버가 아닌 클라이언트 측의 웹 브라우저에 의해 해석되고 적용되는 스크립트이다.

- 자바 스크립트, 비주얼 베이직 스크립트 등

- 이를 CSS(Client Side Script)라 한다.

- CSS는 서버가 아닌 브라우저에서 해석되어 화면에 적용되기 때문에 웹 서버의 부담을 줄여주면서도 다양한 기능을 수행할 수 있다.

Section 04 웹 해킹에 대한 이해

- 웹 해킹은 웹 사이트의 구조와 동작 원리를 이해하는 것에서부터 시작한다.

1. 웹 취약점 스캐너를 통한 정보 수집

- 웹에 대한 정보를 수집할 때는 웹의 메뉴를 하나하나 클릭해보며 수작업으로 동작을 파악하기도 하지만 웹 취약점 스캐너를 사용할 수도 있다.

- 스캐너를 통하면 웹 구조를 파악하고 취약점을 수집하기가 쉽지 않다는 단점이 있다. 각 페이지의 링크 정보를 따라가는 것이므로 웹 페이지에서 링크로 제공하지 않는 페이지는 구조 분석이 어렵다.

- 한편 각 페이지에서 링크 정보를 따라가며 웹 사이트의 웹 페이지를 로컬에 저장해주는 Web Zip이 있는데, 웹 스캔은 Web Zip이 웹 페이지를 수집하는 원리와 같다.

- 웹 프로그램은 자유스럽게 만들어지고 변형도 다양해 웹 스캐너가 취약점을 정확히 잡아내기랑 거의 불가능하다.

- 따라서 스캐너를 통해 발견된 취약점은 개별 확인 과정을 통해 유효성을 확인하는 과정이 필요하다.

2. 웹 프록시를 통한 취약점 분석

- 웹 프록시의 기본적인 동작 구조는 클라이언트에 설치되며 클라이언트의 통제를 받는다. 즉 클라이언트가 웹 서버와 웹 브라우저 간에 전달되는 모든 HTTP 패킷을 웹 프록시를 통해서 확인하면서 수정하는 것이 가능하다.

가. 서버에서 클라이언트로 전송되는 패킷 변조

- 웹 프록시의 유용한 점은 서버와 클라이언트 사이의 패킷을 볼 수 있는 것 이외에 서버와 클라이언트 사이에 전달되는 과정에서 패킷을 위변조할 수 있다는 점이다.

- 변조하고자 하는 패킷은 ASP 혹은 JSP가 아닌 HTML이다. 어떤 언어로 개발됐는지 웹 프록시를 통해서 확인하는 것은 HTML이다.

- 서버에서 클라이언트로 전송되는 내용이 바꾸었으니 자신을 해킹한 것이된다. 하지만 이런 공격이 다음 두가지 위력을 가질 수 있다.

- 첫 번째. 클라이언트에 해킹하고자 하는 대상이 있는 경우

웹 브라우저 내용만 바꾸었지만 실제로는 Active X 등의 형태로 여러 프로그램이 클라이언트에 설치되어 웹 서비스를 제공하는 경우가 많은데, 이때 클라이언트에 설치된 서비스 프로그램을 속이는 것이 가능하다.

- 두 번째. 서버에서 클라이언트에 정보를 전송했다가 이를 다시 전송받아 처리하는 경우

예를 들면 경품을 나눠주기 위한 당첨권은 동전으로 긁으면 '당첨'이란 글자가 나타나므로 가게 주인은 '당첨'이란 글씨를 보고 당첨 여부를 판단할 것이다. 그런데 어떤 사람이 '당첨'이란 글씨를 자신이 받은 당첨권에 위조해서 적으면(이 과정은 마치 서버가 클라이언트에게 전달해준 패킷 값을 위변조하는 것과 같다.) 제대로 위조를 했다면 가게 주인(서버)은 경품을 꺼내줄 것이다.

이처럼 서버가 클라이언트로 보낸 데이터의 변조로 인해 발생하는 위험을 없애려면 서버에서 클라이언트로 전송한 값은 어떤 것도 다시 참조하지 않아야 한다.

나. 클라이언트에서 서버로 전송되는 패킷 변조

- 서버에서 클라이언트로 전송되는 패킷을 변조한 것과 클라이언트에서 서버로 전송되는 패킷을 변조하는 것은 같다.

- 클라이언트에서 서버로 전송되는 패킷을 변조하는 것은, 일반적인 웹 서비스의 메뉴상 접속할 수 없는 것에 접근하거나 특정한 값을 넣어 시스템의 오작동을 유도하기 위한 목적으로 사용된다.

3. 구글 해킹을 통한 정보 수집

- 구글에서 제공하는 고급 검색 기능

- 검색 엔진의 검색을 피하는 방법으로 가장 일반적인 대응법은 웹 서버의 홈 디렉토리에 robot.txt. 파일을 만들어 검색할 수 없게 만드는 방법

Section 05 웹의 주요 취약점 10가지

1. 명령 삽입 취약점

2. XSS 취약점

3. 취약한 인증 및 세션 관리

4. 직접 객체 참조

5. CSRF 취약점

6. 보안 설정 취약점

7. 취약한 정보 저장 방식

8. URL 접근 제한 실패

9. 인증 시 비암호화 채널 사용

10. 부적절한 오류 처리

Section 06 웹 취약점 보완

1. 특수문자 필터링

- 웹 해킹의 가장 기본적인 형태 중 하나가 인수 조작인데 인수 조작은 예외적인 실행을 유발시키기 위해 일반적으로 특수 문자를 포함하게 되어 있다.

- SQL 삽입 공격에서 아이디와 패스워드 넣는 부분에 ' 문자열을 입력받지 못하도록 코드를 수정하여 보완할 수 있다.

- XSS 공격에서 본문에 포함되는 주요 특수문자를 제거하는 함수 등을 사용하여 보완할 수 있다.

2. 서버 측 통제 작용

- 파일 업로드 취약점이나 특수문자 필터링을 수행할 때 주의할 점은 자바 스크립트와 같은 CSS(Client Side Script) 기반의 언어로 필터링을 하면 안된다.

- CSS 기반의 언어는 웹 프록시를 통해 브라우저에 전달되기 때문에 전달되는 과정에서 변조될 가능성이 있다.

- 즉 필터링 로직은 ASP, JSP 등과 같은 SSS(Server Side Sctipt)로 필터링을 수행해야 한다.

3. 지속적인 세션 관리

- URL 접근 제한 실패를 막기 위해서는 기본적으로 모든 웹 페이지에 세션에 대한 인증을 수행해야 한다.

- 모든 웹 페이지에 대해 일관성 있는 인증 로직을 적용하려면 기업 단위에서 또는 웹 사이트 단위에서 세션 인증 로직을 표준화하고, 모든 웹 페이지를 개발할 때 해당 표준을 준수시켜야 한다.

출처 : 정보 보안 개론(한 권으로 배우는 보안 이론의 모든 것) / 양대일 저 / 한빛아카데미 출판