정보보안 스터디 - 11주차 1일 - 파일 취약점 대응방안, 인증/인가 취약점

 

 

 

☞ 다운로드 취약점 우회방법

기존의 다운로드 받아오는 방법은 두가지가 있습니다.

1. 서버에 저장해두고 경로를 다운로드 스크립트로 받아오는 방법 > /uploadbox/ 처럼 따로 디렉토리를 지정해둘 가능성이 높습니다. > 디렉토리 트레버설 취약점이 존재할 수 있습니다.

2. 서버와 상관없이 url에서 직접 가져가도록 하는 방법 > 

장점은 서버의 파일을 받는 것이 아니기 때문에 서버 파일이 유출될 위험이 없습니다.

단점은 허가되지 않은 유저가 받아갈 인가 취약점이 생깁니다. 회원들만 가져가도록 해야합니다.

 

 

파일 다운로드 취약점에서 경로로 지정된 경우에

돼야하는데 ../../ 디렉토리 트레버설이 안먹히는 경우가 있습니다. 주로 /, ., ../ 을 필터링하는데

기호를 필터링했다고 추측할 수 있기 때문에 won../der 을 요청해봅니다. 정상적으로 파일 정보가 뜬다면 

적용이 되것이고 마찬가지로 반복해서 etc/passwd 정보를 받아옵니다. 나머지 다른 필터링은 굳이 사용하지 않습니다.

 

 

☞ 파일 업로드/ 파일 다운로드 취약점 대응방안

업로드, 다운로드 모두 근본적인 대응방안이 있습니다.

서버에 있는 파일들에 접근할 수 없도록 파일들을 DB에 저장해두고 처리하는 것입니다. 데이터를 입력할 때 CLOB / BLOB 속성을 사용합니다. 파일같은 큰 바이너리 데이터를 저장이 가능합니다.

그렇게 된다면 굳이 필터링을 사용하지 않고도 대응할 수 있습니다. 웹쉘 파일을 올려도 DB 테이블에 저장되므로 실행시킬 수가 없습니다. 다운로드 스크립트도 select file~ 로 바뀝니다.

 

재원이 부족해서 DB로 관리못하는 부수적인 경우 사용할 수 있는 방법은

php실행이 안되는 NSA 서버를 만들어 웹쉘 등 아무 파일이나 받되

파일 오는것은 그곳에다가 저장해두고 실제 php실행은 안되도록 하는 것입니다.

 

또한 기존에 스크립트를 수정하는 것이 문제였기때문에

파일 경로를 DB에 저장하고 sqli 쿼리문 스크립트로 변경하여

파일 경로 자체를 불러오게 처리하는 방법도 있습니다.

 

파일업로드

inclusion 취약점에서도 마찬가지지만

path= 나 name= 처럼 변수를 그대로 받지말고

fileid=4, fileid=5 >> SQL : select 5 ~ 처럼 이름을 바꿔서 업로드하거나 다운받아오는 것입니다.

예측이 불가능하게 만들어 놓으면 원하는 파일에 접근하기 어려울 것입니다.

 

 

하지만 여기서 서버내부의 sqli 취약점으로 인해 데이터베이스 테이블 정보를 들여다보게되고

파일 경로가 어디있는지 찾아낼 수도 있습니다.

예를 들어 union select '/etc/passwd',2,3,4 # 로요.

 

 

이부분에 대해서는 더 고민해보고 서버에 직접 구현해보는 것이 좋습니다.

 

 

 

 

☞ 인증 인가 취약점

 

인증이란 내가 나임을 증명하는 것입니다.

인증취약점은 그런 증명하는 과정을 건너 띌 수 있는 취약점을 말합니다. 스킵하거나 데이터를 안보내도 접근가능합니다.

예를 들어 로그인 하는 과정을 건너 띄고 다음단계에서 유저의 접근이 가능해서 행동을 할 수 있다거나 마이페이지에서 비밀번호 변경 등이 있습니다.

 

인가란 어떤 행동을 하도록 허락해주는 것입니다.

인가취약점은 일반 유저에게 아무나 할 수 없어야하는 행동을 가능하게 합니다.

예를들어 일반 유저의 비밀번호 변경이나, 글 수정을 마음대로 할 수 있다거나, 댓글 수정 등이 있습니다. 

 

이 인증/인가 취약점들은 실무 현장에서 의도치않게 가장 많이 접할 취약점들이고,

실수들로인해 많이 생겨나는 취약점입니다.

완벽한 사람은 없듯이 완벽한 웹은 없습니다. 완벽하게 막아놓은 듯해도 외주 개발자들의 짬뽕같이 만들어놓고 가고 여러 외주 개발업체에서 개발환경을 건들여 놓습니다. 시스템 관리자나 보안 담당자가 손을 쓰기도 싫고, 쓸 수 도없는 상황이 만들어집니다. 당장은 완벽하게 막아놓았다고 해도 앞으로 서비스는 더 추가 될 것이고 같은 실수를 반복하거나 새로운 취약점들이 일어날 수 있습니다. 개발자들이 보안에 통달한것도 아니고 염두하면서 완벽하게 구현하기가 힘들기 때문입니다.   

그리고 개발자들이 너무 복잡해지면 이것저것 테이프 붙은것처럼 복잡해져서 건드릴 엄두도 안나고 

수정을 하려고할 때 이걸건드리면 다른 기능이 고장나고, 하는 경우가 매우 많습니다. 

그렇기 때문에 수정하기를 꺼려하고, 수정을해도 한두 문장 최소한으로 수정하려고합니다.

 

 

인증 취약점 사례로 예를 든다면

인증취약점 단계별 발사 step1 > step2 > step3

step1에서 step2로가고, 3으로 가려면 관리자 비밀번호가 필요합니다.

근데 만약 그냥

합리적 추측으로 다음 단계는 step3 겠네. 라고 추측할 수 있겠고 만약 구현이 잘 안되었다면 세션없이 일반 유저의 접근으로도 접근이 가능할 것입니다. 말도 안된다고 생각할 수 있지만 생각보다 실제 현장에서 많이 나오는 방식이고, 제가 서버를 만들어보면서도 왜 여기에 세션 검증을 안넣었지? 하는 순간들이 있습니다.

 

그리고 주석 취약점이 있습니다.

주석부분에 버튼링크를 달거나 , 공지사항 게시판인데 글쓰기를 다는 경우가 있습니다.

그럴 경우에는 서버 응답을 intercept해서 주석을 없애보는 방법을 시도해서 숨겨진 기능을 사용할 수도 있고

주석에 많은 내용이 담겨져있습니다.

 

이렇게 주석을 남기는 실수를 하는 이유는 

마찬가지로 외주 업체가 많이 거쳐갈텐데 서버와 관계된 관계자들이 봤을 때 어떤 내용인지 자세하게 남겨놔야 다음에 수정하거나 기능을 사용할 때 기능에 대해 알 수 있습니다. 또한 잘못 될 경우를 생각해 삭제하긴 아깝고 주석처리하는 경우가 있습니다. 그렇기 때문에 아주 자세하게 남겨놓기 때문에 주석을 실수로 클라이언트 측으로 공개할 수도 있고, 만약 소스코드를 탈취당하게 된다면 주석을 보고 많은 2차피해를 남길 수 있습니다. 

 

항상 취약점이 있고, 신경쓸곳이 여러곳이기 때문에 그래서 보안 인력이 부족하다고 하는 것입니다.  

 

 

 

인가취약점  ex) 몰래보기

글 읽는 방법은 클릭해서 글읽기, id=글번호로 url리다이렉션하기 뿐만아니라 글수정으로도 볼 수 있습니다. 글수정에서 만약 개발이 제대로 안되었다면 글번호로 관리자만 읽을 수 있는 글을 불러왔을 떄  글 수정 페이지에서 글이 보이는 현상이 일어나게 됩니다. 이런부분은 사실 웹브라우저의 눈으로만 보이는 것이 다가 아닙니다.

항상 burp suite에서 코드로 보는 습관을 들여야하고 분명히 웹브라우저에서는 안나오거나 엉망이었던 것이 burp suite에서 정확히 보일 때가 많습니다.

글수정

그걸 처음에 생각을 하고 방법을 떠올리면 글수정이 

 

잘못 설계해 개발자의 설계적 취약점이라고 볼 수 있습니다. 이것 또한 주의깊게 찾아볼 가치가 있는 취약점입니다. 사소해보이지만 2차공격으로 이끌어갈 발판이 될 수 있습니다. 

 

 

잔머리 습관화 해야합니다. 일상생활에서 인증/인가로 취약점이 뭐가 있을까 생각하면 분명히 나오고 취약점 찾기 연습하는데 도움이되고 무엇보다 재밌습니다.