R4v!dus

CSRF는 Victim의 의지 및 의도와는 무관하게 Attacker가 의도한 특정 행위를 웹 사이트에 요청하는 공격 기법이다.

원리는 사용자가 웹 사이트에 로그인한 상태에서 CSRF 공격 소스가 삽입 된 페이지를 열면 웹 사이트를 공격 하게 된다.

웹 사이트는 신뢰하는 사용자의 요청이기에 이를 수행함으로써 공격에 노출되게 되는 것이다.

굉장히 많은 종류의 CSRF 모식도가 그려져 있는데 그중 하나를 퍼왔다. 이를 이용하여 설명 하고자 한다.

1.공격자가 사용자에게 공격소스가 삽입된 페이지를 보낸다.

2.로그인 되어 있는 사용자는 이를 실행하고 소스 대로 여러가지 행위를 요청한다.

3.웹은 소스대로 행위에 대한 결과 값을 공격자에게 송신한다.

이 모식도는 사용자의 정상적인 Session값을 탈취하여 공격자가 사용자를 대신하려는 것으로 보인다.

CSRF는 위 그림과 같은 일련의 방식으로 일어난다.

사용자가 어떻게든 공격 소스를 실행 하게끔 만드는게 이 공격 기법의 핵심이며 이를 위해 여러 방법이 사용된다.

(방법에 따라 모식도가 조금씩 달라진다.)

대응 방안

-Referrer 검증

Back-end에서 requet의 referer를 확인하여 전에 들어온 주소와 도메인이 일치하는지를 검증 하는 방법이다.

쉬운 보안이지만 CSRF의 전반적인 공격의 방어가 가능하다. XSS취약점이 존재할 경우 방어가 무의미하며 리퍼의경우 값이 변조 될수 있다. 그러면 어떻게 해야되는가?

X-CSRF 커스텀 헤더를 사용하는것이다.

웹 브라우저는 커스텀 헤더를 다른 도메인으로 전달하지 않는다.

따라서 공격자가 공격 페이지를 만들더라도 X-CSRF 헤더가 포함되지 않음을 알수 있다.

그렇다면 만들면 되지 않느냐? 아니다 XHR객체를 사용하더라도 정상적인 요청은 생성할 수 없다.

-CSRF Token 사용

사용자 세션에 임의의 값을 저장하여 모든 요청에 대하여 서버단에서 검증하는 방법이다.

XSS 취약점이 있을경우 무용지물

-Double-Submit Cookie Pattern

웹 브라우저의 Same Origin 정책으로 공격자가 쿠키값에는 접근 할수 없다는 점을 이용하여 브라우저는 토큰 값과 시크릿키값을 서버로 부터 받는다.

브라우저에서 write 요청시 header에 토큰 값을 주고 쿠키 값에 시크릿키를 부여하여 서버의 미들웨어에서 토큰값을 decode해 decode한 시크릿 쿠키 값과 일치하는지 체크한다.

XSS나 메타태그를 이용하여 쿠키값을 조작 할 수 있어 완벽하지는 않다.

사진 참조: https://stackhoarder.com/2019/08/19/laravel-%EA%B8%B0%EB%B3%B8-10-csrf-protection/

-경쟁상태

둘 이상의 입력 또는 순서 등이 결과값에 영향을 줄 수 있는 상태를 말한다. 입력 변화의 타이밍이나 순서가 예상과 다르게 작동하면서 정상적인 결과가 나오지 않을 위험이 있는데 이를 경쟁 위험이라고 지칭 한다.

컴퓨터 메모리 또는 스토리지에서 데이터를 읽고 쓰는 명령들이 같은 순간이라고 해도 될정도로 순식간에 처리된다.

그 일련의 과정 중 이전 데이터가 여전히 있는 동안 데이터의 일부 또는 전부를 덮어 씌우려 할 때 경쟁 상태가 발생한다.

프로세스1은 비트 플립을  수행하여 메모리값을 0->1 프로세스2도 비트플립을 수행하여 메모리값을 1->0으로 변경시킨다.

여기서 경쟁상태가 발생하여 두 프로세스가 겹치면 어떻게 될까?

메모리 값이 0이어야 하는 마지막 경우의 메모리 값은 1이 되어 있다. 이는 프로세스1이 동시 비트플립을 수행하고 있다는 것을 프로세스2가 파악하지 못하기 때문에 나온 결과이다.

-경쟁 상태로 인한 취약점

프로그램이 둘 이상의 작업을 동시 수행 하도록 하면 공격자는 교착 상태 또는 스레드 블록 상황을 만들기 위해 시작 시점과 보안 제어가 적용 되는 시점 사이의 시간 간격을 활용 할 수 있다.

(교착상태는 소프트웨어 시스템의 정지를 스레드 블록은 응용 프로그램 성능에 영향을 줄 수 있다.)

- 대응 방안

메모리 또는 스토리지 엑세스의 직렬화를 통해 경쟁 상태를 방지 할 수 있다.

webhacking.kr의 60번 문제가 네트워크에서 이를 이용하여 해결하는 문제다.

뭐 여러가지 필터링이 되어 있고 get방식으로 보내진 id 가 쿼리문을 지나 받은 result가 admin이면 풀린다는 것 같다.

이 문제는 컬럼 별칭을 이용해  원하는 컬럼에 값을 넣도록 해서 해결하는 방식이다.

select {$_GET['id']} from chall61 order by id desc limit 1

내림차순으로  1개만 골라 낸다는 뜻이다.

평소 자주 쓰던 char()은 필터링에 걸려 있다.

hex값으로admin을 넣어주면 의미는 같다.

0x61646d696e id

select 0x61646d696e id from chall61 order by id desc limit 1

id라는 컬럼에 0x61646d696e값이 들어가고 id라는 컬럼을 내림차순으로 하나라는 뜻이다.

클~

파일 하나가 생성되고 1초만에 지워진다.  이 파일을 건드릴수 있다면 문제가 풀린다.

쿠키값을 겹치지 않게 숫자로 수정해주고 재로그인한후 ?mode=auth로 접속했다.

vm을 사용해서 파일을 생성하였고, 삭제되기전에 크롬으로 낚아챘다.

클

소스 코드를 통해 result['lv'] == admin 이면 문제가 풀린다는 것과 lid, lphone은 login을 id, phone은 join과 연관 있다는 것을 짐작 할 수 있다.

id는 admin이란 글자가 필터링 되어 있으며 phone은 20자리가 넘으면 안된다고 되어 있다.

ladmin이 되게 생성 해주고 그 계정으로 로그인 하면 풀릴 문제다.

 echo "id : {$result['id']}<br>lv : {$result['lv']}<br><br>";

음 id, lv이 표시되나보다. 이걸로 확인 하면서 구문을 수정해 나가면 될듯 하다.

reverse 함수를 이용하여 문제를 풀도록 했다.

주석을 사용하여 뒷 구문을 다 씹도록 하였다.(phone에 숫자는 뭐가 들어가든 상관 없다.)

insert into chall59 values('{$_POST['id']}',{$_POST['phone']},'guest')

이를 보면 id, phone, guest 순으로 값이 정렬된다.

insert into chall59 values(nimda,1,admin);-- ,'guest')

구문에 따라 값을 넣어보면 이런식으로 들어간다.

insert into chall59 values(nimda,1,admin);-- 

주석문으로 뒤를 다씹게 되면 온전한 하나의 쿼리문이 된다.

클

공허하다 음 뭔가 입력할수 있는듯 싶다.

아무값이나 입력 했더니 command not found란다.

command라길래 help를 입력해 봤다.

사용할수 있는 커맨드가 보여진다.

다른건 별 소용이 없어 flag를 쳐보았다.

admin이 아니면 안보여주나 보다.

당장에 더이상 얻을수 있는게 없어서 소스코드를 확인했더니 script구문이 있었다.

심지어 username default가 guest로 되어 있는 것까지 확인했다. 이걸 admin으로 바꿔 보내면 될듯 싶다.

코드를 콘솔에 입력해주고 다시금 falg를 요청하면

flag를 준다.

클