1. XSS
약 1주동안 다른건 안하고 XSS에서 html 인코딩을 우회할 수 있는 방법을 찾아보았었다.
이게 가능하다면 이미지 태그나 스크립트 태그 등 XSS를 발생시킬 수 있는 좋은 무기가 될 것이기 때문이다.
그래서 일주일동안 찾아보면서 낸 결론은 "불가능하다"이다.
구글에 Bypass HTML Encoding XSS라고 치면 여러가지 자료와 영상이 나오길래 방법이 있는 줄 알았고 이를 계속 보고있었다. 자료를 찾아볼 본 일주일의 시간동안에는 거기에서 작성한 XSS 페이로드를 내가 만든 사이트(게시판)에다가 적용해보았고 다 실행되지 않았다.
그러다 일주일차가 되는 어제 내가 멍청한 짓을 하고 있었음을 알았다. 이를 알기 위해서는 XSS에도 종류가 있다는 사실부터 알아야 한다.
1) Stored XSS
이는 게시판의 게시물같이 서버에 Stored(저장)되는 것에다가 스크립트를 삽입해 피해자가 해당 게시물같은 것을 조회하면 서버가 그 스크립트가 들어있는 게시물을 응답으로 뱉어 피해자의 권한을 가지는 세션이나 쿠키같은 것을 탈취하는 것을 말한다.
내가 어제 작성했던 TIL에서 해봤듯이 게시물에다가 온갖 스크립트를 넣어서 글을 업로드하는 것이 Stored XSS인 셈이다.
2) Reflected XSS
이는 검색같은 요청처럼 서버에게 어떠한 요청을 보내고 해당 요청에 대한 응답을 받는 동작에 대해 수행할 수 있다.
예를들어 흔히 검색창에 "사과"라고 치면 사과와 관련되어 있는 내용들을 뱉을 것이다.
그치만 만약에 검색결과가 없을법한 "asdjfklasdjfklasd"같은 내용을 치면 어떤 사이트에서는
"asdjfklasdjfklasd"와 관련된 내용이 없다고 해당 페이지에 출력을 할 것이다.
문제는 여기서 발생한다.
그럼 만약에 get으로 받는 검색창의 인자에 스크립트 태그나 이벤트핸들러 태그로 작성된 페이로드를 넣는다면 어떻게 될까?
검색결과 페이지에 "해당 페이로드"에 대한 결과가 없습니다. 라고 뜰텐데 이에 대한 처리가 잘 되어있지 않다면 이미 html단에 페이로드가 삽입된 것이므로 이벤트핸들러나 스크립트의 내용이 실행이 됐을 것이다.
3) Dom Based XSS
이는 나중에 더 공부해보고 다시 올릴 것이다.
4) 내가 멍청했던 점
일단 Stored와 Reflected의 차이점이 두개가 있는데,
첫번째로 Stored XSS는 피해자가 악성 게시물을 조회하면 그냥 된다는 것이고,
Reflected에서 공격자는 피해자가 서버로 요청을 보내는 URL을 피해자가 클릭하도록 어떻게든 유도를 해야한다는 것이다.
두번째는 Reflected는 Stored와 다르게 URL을 사용한다는 것이다.
그리고 나는 전부터 Stored XSS를 시도하고 있었고 html encoding을 우회하기 위해 일주일이라는 시간을 찾아보고 있었다.
그리고 구글에 있던 우회법들은 대부분 공통적으로 URL 인코딩을 하는 모습을 보이고 있었는데 그래서 나도 "게시물"에다가 URL 인코딩한 것을 넣고 업로드를 하고 있었다.
애당초 게시물의 내용이 URL에 들어갈 일이 없는데 그런 짓을 하고 있었던 것이다.
결론적으로 구글에서 시연하던 우회방법들은 Reflected XSS를 우회할 수도 있는 방법들을 가르쳐주고 있었는데 나는 그 방법을 Stored XSS에 적용하고 있던 것이다.
그리고 문득 든 생각이 Stored XSS의 html encoding을 우회할 수 있는 방법이 있었다면 이미 script나 img 태그 등 XSS 위협이 있는 태그들이 모든 사이트에 삽입될 수 있었다는 것이고 그럼 진작 세계 모든 사이트를 해킹할 수 있었다는 것이다. 아직까지 안 뚫렸다는 것은 방법이 없다는 뜻이다.
랩실 프로젝트 릴리즈가 그렇게 많이 남지는 않은걸로 아는데 이렇게 벌써 몇 개가 막혀버리니 참 막막하다. 심지어 검색기능도 Elastic Search라는 엔진으로 get이 아닌 post로 할 것 같아서 어떻게 해야할지 감이 안 온다.
어찌되었든 쓸데없는데 일주일을 날린 시간이 너무 아깝다....
2. PLT & GOT
이는 ASLR(Address Space Layout Randomization)과 NX(No-Executable)라는 메모리 보호 기법을 공부하다가 동적 라이브러리 할당에서 PLT와 GOT라는 개념이 나와 진짜 야매로 간단하게 정리를 해보았다.
먼저 ASLR과 NX에 대해 정말 간단하게 한 줄로 정리하면 이렇다.
(정확한 동작원리와 취약점이 있을 시 우회하는 방법은 다음에 해볼 것이다.)
ASLR : 바이너리가 메모리에 적재될 때마다 그 장소가 랜덤화 됨
(== 버퍼의 위치나 함수의 위치같은 것이 고정되어있지 않게 됨)
NX : 각 세그먼트(스택, 코드, 힙...)에서 쓸데없는 권한을 빼는 것
(== 스택세그먼트에서는 실행권한이 필요없으며(return address 변조 방어),
코드세그먼트에는 쓰기권한이 필요없다(코드영역에 악성코드 삽입방지))
하지만 여전히 "라이브러리"는 실행권한을 가지는 "코드영역"에 있을 것이고 PLT와 GOT가 잘못되어있다면 이곳에서 해킹이 일어날 수 있을 것이다.
본격적으로 PLT와 GOT에 정말 간단히 알아보면
예를들어 printf를 두번쓰는 정말 간단한 코드가 있다고 해보자
#include <stdio.h>
int main(){
printf("First Call");
printf("Second Call");
}라이브러리는 말그대로 도서관이고 위의 프로그램이 이 도서관을 이용하는 사람이라고 생각해보자
일단 printf라는 책을 처음 찾기 위해 도서관을 방문한 사람은 해당 책을 찾기 위해 사서선생님(PLT)을 찾아가서 "printf 책 어딨어요?"를 물어본 뒤 그 책이 실제로 존재하는 곳에서 참고하여 printf를 실행할 것이다.
하지만 두번째 printf를 실행할 때 다시 도서관에 와서 또 사서선생님께 "printf 책 어딨어요?"라고 여쭤보고 가기엔 시간과 효율이 아깝기에 그냥 그 책이 어딨는지 프로그램단에서 기억(GOT)을 해둔다.
하지만 결국 그 프로그램을 만지는 사람은 우리이기에 이 기억(GOT)을 조작할 수 있다.
그래서 두 번 이상 실행되는 같은 명령어의 GOT를 printf가 아닌 system함수의 실제 위치로 조작을 하게 된다면 두번째 printf가 실행될 때 printf 대신 system함수가 실행되면서 해킹을 할 수 있는 위험이 생긴다.
이에 대한 예시와 실습은 조금 더 공부하고 다음에 해볼 것이다.
