rubiya 님의 Stored XSS 글을 보다가 몇가지 실험을 해보았고, 그 결과를 공유한다.

일단, rubiya님의 글은 다음과 같다.

간단히 해당 글을 요약하자면, 웹해킹 분야의 워게임 사이트인 webhaking.kr에 존재하는 문제 중 운영자가 의도하지 않은 취약점이 해당 문제에 존재하였고, 해당 취약점을 이용하여 Stored XSS가 이루어진다는 내용이다.

Stored XSS가 단순히 게시글 등록으로 이루어진 것이 아니라, Indirect SQL Injection을 통해 이루어졌다는 점도 흥미롭다.

Indirect SQL Injection에 대해서는 바로 이전 포스팅에서 간단히 설명해두었으니 해당 게시글을 참고해주길 바란다.

모든 내용이 이해가 갔는데, 1.jpg 부분을 통해 소스코드를 발견한 부분이 참 흥미로워서 개인적으로 확인 및 추가 실험을 진행해보았다.

일단 실제로 [tar -cvf *]를 하였을 때 실제로 첫번째 파일에 해당 디렉토리의 모든 파일의 내용이 들어가는지 확인해보았다.

1. 실제 동작하는지 확인

먼저 디렉토리에 3개의 파일이 있는 상태이고, 가장 첫번째 파일의 크기는 9Byte임을 알 수 있다.

이 상태에서 tar -cvf *를 하였고 그 결과 2개의 파일(2.txt, 3.jpg)가 묶였다는 것을 볼 수 있으며 1.jpg 파일의 크기가 10240으로 크게 바뀐 것을 통해 묶인 결과가 1.jpg로 된 것을 볼 수 있다.

vi로 1.jpg를 확인하였을 때 2.txt 파일에 들어있는 [FLAG!!]라는 문자열도 보이는 것을 확인할 수 있다.

이는 tar 명령어를 사용할 때 압축결과 파일명을 따로 작성하지 않을 때 해당 디렉토리의 첫번째 파일에 묶인다는 것을 이용한 것이다.

이 분석을 통해 [웹 서버에서 접근 가능한 디렉토리에는 tar 파일을 두지 않아야하며 만약 둬야한다면 예측 가능한 tar 파일명을 쓰지 않아야한다] 정도의 교훈(?)을 얻을 수 있었다.

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

Q. 만약 명령어를 사용할 수 있는 상태이지만 로그인된 user명이 권한이 낮아 root 권한만 읽을 수 있는 파일을 읽지 못하는 상황이라면?

A. 당연히 tar 를 이용해서도 볼 수 없다.

3개의 파일(1.jpg, 2.txt, 3.jpg) 파일이 root 만 볼 수 있는 파일일 때 tar -cvf *를 하면 Permission denied가 뜨며 묶을 수 없다. 

뭔가 당연한데 혹시나 될수도 있지 않을까 했는데 역시나였다..ㅋㅋㅋ

오늘은 인터넷을 돌아다니다가 [Indirect SQL Injection]이라는 것에 대해 알게 되었다.

일단 Indirect SQL Injection이란 무엇을 의미하는지 보도록 하자.

말그대로 번역을하면 간접적인 SQL Injection이다.

이를 조금 더 풀어서 이야기하자면 비정상적인 데이터를 삽입하였을 때 바로 Injection이 터지는 취약점이 아니라, 삽입한 데이터가 조회될 때 비로소 Injection이 터지며 정보가 노출되는 취약점이라 생각하면 된다.

이에 대한 예시는 아래 블로그를 참고하였다.

이 두 블로그 글을 참고하면 어떤 느낌인지 올 것이다.

Real World에서도 충분히 발생될 수 있다는 생각이 들었고, 추후 개발할 때에도 신경써서 개발해야겠다는 생각이 들었다.

만약 Indirect SQL Injection과 관련된 Writeup을 작성하게 될 경우 해당 포스팅을 링크걸어둘 생각으로 작성해둔다.

파일 다운로드 취약점이 발생되었을 때 DB에 접근할 수 있는 정보 혹은 업로드하는 파일의 소스코드를 봐서 FU 취약점이 발생될 수 있는지를 확인한다. 이 때 Spring Framework에서 Controller의 위치를 한번에 알 수 있는 방법이 있는지에 대해 공부한 일련의 과정을 정리해둔다.

※ View 위치 찾기

1. /WEB-INF/web.xml

 (1) Spring에서 MVC를 구현하기 위한 Dispatcher Servlet을 찾는다.

 (2) Dispatcher Servlet에 포함되어 URL Mapping을 담당하고 있는 servlet-context.xml의 경로를 찾는다.

그림1. /WEB-INF/web.xml (출처 : https://all-record.tistory.com/165?category=733072)

◎ 만약 위와 같이 servlet-context.xml이 존재하지 않은 경우

contextConfigLocation 초기화 파라미터를 설정하지 않은 경우, DispatcherServlet은 WEB-INF/[서블릿이름]-servlet.ml 파일을 설정파일로 사용한다.

2. servlet-context.xml 경로

 (1) Controller에 의해 리턴된 View를 찾아주는 ViewResolver를 찾는다.

 (2) 해당 ViewResolver의 속성인 prefix와 suffix를 통해 내가 요청한 URL의 view page가 어디인지 찾는다.

그림2. servlet-context.xml (출처 : https://all-record.tistory.com/165?category=733072)

※ Controller 위치 찾기

view는 찾기 쉽지만 우리가 원하는 실제 코드는 controller에 있다. 이를 찾기 위해서는 우리가 URL에 입력한 것이 각 controller의 @RequestMapping Annotation에 있는지를 찾아야 한다.

그렇다면 각 controller의 파일명을 알 수 있는 방법이 있을까?

정확하지는 않지만 일단 지금까지의 결론은 다음과 같다.

1. web-xml에 dispatcherServlet을 등록함

2. dispatcherSerlvet 안에 <annotation-driven />과 함께 component-scan을 통해 패키지 안에 @controller라고 적어둔 annotation을 기준으로 컨트롤러를 스캔한다.

3. 이후 요청은 스캔한 컨트롤러들을 기준으로 동작한다.

결론 : 모든 컨트롤러가 적혀있는 특정 파일은 존재하지 않다.

추가적으로 더 알게된 내용이 있으면 추가하겠음.

참고 ) 

이론 : https://all-record.tistory.com/165?category=733072

실제 파일 위치들 예제 : http://pgm-progger.blogspot.com/2014/01/spring-base-setting.html

mysql에서는 SQL Injection을 통해 파일 다운로드 취약점, 파일 업로드 취약점으로 나아갈 수 있는 방법이 있다. 이는 바로 load_file 구문과 into outfile 구문을 이용하는 것이다.

해당 구문을 이용한 취약점에 대해서는 구글링할 것을 추천하고 해당 포스팅에서는 SQL Injection 이후 해당 구문들을 사용할 수 있는지 확인하는 것에 포커스를 두었다.

1. SQL Injection을 통해 DB 정보 획득

 - user명 : select user();

 - version 정보 : select @@version;

- file-priv 옵션 : select user, file_priv from mysql.user;

2. secure-file-priv

 - 현재 user에게 file-priv 옵션이 Y로 지정되어있다라도 secure-file-priv 옵션이 지정되어있으면 해당 디렉토리 이외에는 읽기/쓰기가 불가능하다.

만약 위와 같은 에러가 떴다면, 이는 secure-file-priv로 지정한 디렉토리 이외의 디렉토리에 존재하는 파일을 읽거나 쓰려고 했기 때문이다.

 - MYSQL 5.6.34 이후의 버전에서는 보안 문제로 인해 secure-file-priv 옵션이 지정되어 있지 않을 경우에도 위와 같은 에러문이 출력되며 load_file과 into outfile 구문을 사용할 수 없다.

※ secure-file-priv 확인 방법

 * 명령어 :  SHOW VARIABLES LIKE 'secure_file%';

 * 옵션 설정 파일 예시

   - 리눅스 :  /etc/my.cnf  or /etc/mysql/my.cnf

   - 윈도우 : C:\ProgramData\MySQL\MySQL Server 5.6\my.ini

문제에 접근하면 오직 gif 파일만 올릴 수 있다고 한다.

혹시 내가 모르는 취약점이 존재하지 않을까 하여 소스코드 내 여러 함수들을 보았지만 딱히 그래 보이는 것은 없었다.

그래서 gif와 php에 대해 검색을 하다보니 gif 파일 내에 포함되어 있는 PHP code가 실행이 되는 취약점이 존재하는 것을 보고 시도해보았다.

임의의 GIF 파일 내에 TEST 문자열 출력 코드를 삽입한 결과 잘 동작하는 것을 볼 수 있다.

이를 통해 간단히 풀 수 있겠다 하여 system 함수를 이용하여 시스템 명령어를 출력하려하였지만 동작하지 않았다. 하지만 phpinfo()를 해보았을 때도 역시 제대로 동작하는 것을 통해 시스템 명령어를 사용할 수 있는 함수들은 차단한 것으로 보인다.

그래서 PHP 함수 중 디렉토리 내 파일들을 확인할 수 있는 함수를 찾다 scandir 함수를 찾아 이를 통해 현재 디렉토리 내 파일들을 볼 수 있었다.

이후 show_source() 함수를 이용하여 flag.txt 를 읽어 FLAG를 획득하였다.

새로 알게된 사실들

1. scandir은 PHP 5 이상 지원한다. 그 아래의 PHP를 사용할 가능성은 낮지만 만약 그 아래라면 opendir, readdir, closedir 함수를 이용하여 동일한 기능을 이용할 수 있다.

2. echo, print_r, var_dump의 차이점은?

 - echo는 단순 출력용 ( 배열을 출력하면 array라고 출력된다. )

 - print_r의 경우 배열이나 객체를 출력할 때 사용된다.

 - var_dump는 print_r과 비슷하지만 각 값들의 type까지 알려준다.

3. gif 확장자에서 PHP Code가 실행되는 이유는?

해당 문제는 PHP의 parse_url 에서 발생하는 취약점을 이용하는 문제이다.

CTF에서도 자주 나오는 문제이므로 추후 한번 정리하여 포스팅을 할까 한다.

일단 문제를 확인해보면 flag.txt 안에 flag가 존재하는데 page 파라미터에 flag를 넣으면 된다.

코드를 확인해보자.

<?php
	parse_str(parse_url($_SERVER['REQUEST_URI'])['query'], $query);
	foreach ($query as $k => $v) {
		if (stripos($v, 'flag') !== false)
			die('You are not allowed to get the flag, sorry :/');
		}

	include $_GET['page'] . '.txt';
?>

코드를 확인해보면 REQUEST_URI를 parse_url한 뒤 그 중 query 부분에 대하여 값에 flag가 들어가면 die() 시켜버리는 것을 볼 수 있다.

따라서 parse_url의 취약점을 이용하여 제대로 파싱하지 못하도록 만들어주면 된다.

일단 아래 테스트한 사진들을 보자.

1. 기본

가장 기본적인 것으로 단순히 flag를 제출했을 때 parse_url 결과 각각 어떻게 되는지 볼 수 있다.

세번째 query 부분을 level 24 문제의 관점에서 봤을 때 $k에 page가, $v에 flag가 들어가서 die 함수에 의해 실행이 종료되는 것을 볼 수 있다.

2. double slash(//) 이용

이번엔 host와 path 사이에 double slash를 넣어보았다. 이전 사진과 비교해봤을 때 달라지는 것은 바로 websec.php가 path가 아닌 host가 되었다는 것이다. 

이것은 //가 기본적으로 http://로 동작하기 때문에 이런 현상이 나오는 것이다. 이것은 보통 홈페이지 작성 시 리소스 부분을 보면 src="//rootable.tistory.com/1.png" 과 같이 사용되는 것으로도 자주 볼 수 있다.

하지만 여전히 query 부분에 page=flag가 되어있기 때문에 solve할 수는 없다.

3. triple slash(///) 이용

이번엔 double이 아닌 triple로 해보았다.

이번엔 parse_url이 제대로 파싱하지 못했기 때문에 parse_url의 결과가 false로 떴다. 그 이유는 // 이후 다음에 나올 / 전에 문자열이 존재해야 host로 파싱을 해야하는데 그 사이에 문자열이 존재하지 않기 때문에 host가 존재하지 않다고 판단을 하고 false로 리턴하는 것이다.

그 결과, query 부분에 flag가 들어가지 않았으며 따라서 $v에 path가 존재하지 않다는 뜻이므로 if문을 넘어 flag.txt를 include하여 문제가 풀린다.

파싱이 제대로 되지 않도록만 하면 되기 때문에 /// 뿐만 아니라 4개, 5개를 활용해도 제대로 파싱되지 않아 문제는 풀린다.

(기타) 또 다른 방법

그렇다면 다른 방법이 더 존재하지 않을까?

이를 위해 parse_url의 포트를 활용하는 방법도 있다.

이는 PHP 5.4.7 미만의 버전일 때만 가능하다.

자세한 정보는 https://bugs.php.net/bug.php?id=74780 를 참고하길 바란다.

만약 query 부분에 콜론이 들어갈 경우 5.4.7 이전의 버전일 경우에는 parse_url이 파싱에 실패한다고 한다.

물론 이 때 콜론 뒤에 숫자형태로 와서 포트로 인식되도록 해야 한다.

websec.fr level25에 적용해보면 send 뒤에 :80 을 넣어서 문제가 solve가 된 것을 볼 수 있다.

이는 websec.fr/level25/index.php?page=flag&:1과 같이 반드시 파라미터형태로 전달해주지 않아도 bug가 발생한다.

해당 문제는 느슨한 문자열 비교에 의해 발견된 취약점을 이용한 문제이다.

먼저 소스코드를 분석해보면 sleep_rand(); 함수를 선언하고 post 방식으로 flag 값이 세팅되어있으면 해당 함수를 호출하는데 이는 flag를 찾는 것과는 무관하다.

그냥 말 그대로 random한 값대로 sleep 하는 함수이다.

중요하게 봐야할 곳은 바로 아래 쪽이다.

<?php
if (! strcasecmp ($_POST['flag'], $flag))
    echo '<div class="alert alert-success">Here is your flag: <mark>' . $flag . '</mark>.</div>';   
else
    echo '<div class="alert alert-danger">Invalid flag, sorry.</div>';
?>

POST 방식으로 넘겨준 flag 파라미터값과 $flag 변수의 값이 일치할 경우 $flag를 출력해준다고 한다.

strcasecmp는 strcmp와 동일한 함수인데 단지 대소문자 비교를 하지 않는다는 차이만 존재하다.

따라서 strcmp의 취약점을 통해 flag를 배열로 넘겨주면 flag가 출력된다.

※ strcmp 취약점

 - strcmp(str1,str2)의 경우 return 값이 총 3가지 경우로 나눠져있다.

1) str1>str2 => 양수

2) str1<str2 => 음수

3) str1=str2 => 0

 - PHP 5.3 이상의 버전에서 문자열과 배열을 비교하게 되면 NULL을 출력한다. PHP 5.2 이하 버전에서는 문자열과 배열을 비교했을 때 문자열과 "Array"를 비교한다고 한다.

 - 문자열 비교 시 느슨한 비교(==)를 할 경우 NULL과 0을 비교하면 True가 되므로 문자열을 알지 못하더라고 배열을 넣으면 두 가지 인자값이 동일하다고 판단하는 것이다.

자세한 사항은 아래 블로그를 참고하길 바란다.

https://hackability.kr/entry/PHP-strcmp-%EC%B7%A8%EC%95%BD%EC%A0%90%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%9D%B8%EC%A6%9D-%EC%9A%B0%ED%9A%8C