웹 모바일 취약점 점검 교육 후기? -1

2월 27일 28일 이틀간 취약점 점검에 대한 교육을 받았다.

 

첫 날은 웹에 대한 두 번째 날은 앱에대해 취약점 점검을 배웠는데, 두 강사님 모두 하루는 짧다고 생각하셔서 세부적인 내용보단 어떻게 공부를 해야하는지 어떤 흐름으로 취약점을 찾아내는지 등 전체적인 느낌들을 알려주셨다.

 

 

 

 

 

1일차 웹

 

웹 해킹 툴에 대하여

 

강사님은 처음부터 실무에선 owasp zap같은 툴이 무용지물이라고 말씀해주셨다.

툴을 사용한 스캔은 웹 방화벽에 막혀버려 모의 침투에서도 쓰이지 않고 탐지도 너무 쉽게 되어서 실질적으로 사용하기가 어렵다는 이유였다. 하지만 우리같은 학생이 배우고 학습하기에는 좋은 툴이라는 말씀을 끝으로 툴 소개를 마치셨다.

 

 

 

 

 

웹방화벽 관련

 

예를 들어서 공격자가 침투에 성공하여 서버를 조작하게 되었는데 방화벽에는 이 행위가 로그에 찍히는지 안찍히는지 질문을 하셨다.

내가 군대에 있을때는 허용로그 거부로그 다 탐지가 되어서 당연히 찍히지라는 생각을 하였는데, 실무에선 허용로그까지 기록하게 되버리면 현실적으로 감당할 수 없는 로그의 양을 관리하게 되어서 거부로그만 탐지되게 한다고 하셨다. 그러므로 침투에 성공하면 로그를 확인할 수 없다.

 

 

 

 

OWASP top 10 취약점 관련

 

파일 업로드 / 다운로드

sql injection

session jacking

xss

소스코드 노출

 

위 취약점들은 OWASP top 10 에서 빠진적이 거의 없다고 하심.(위에서부터 3개의 취약점은 단 한번도 top10에서 빠진적이 없음)

 

 

 

 

 

 

실무에서 취약점 점검을 할 때 관련

 

풋프린팅이라고하는 정보 수집단계가 중요하다고 하심. 

[풋프린팅(Footprinting)은 컴퓨터 시스템들과 그것들이 속한 엔티티들에 대한 정보를 모으는 기법이다. 이것은 다양한 컴퓨터 보안 기법들을 이용한다.]

원래는 어떤 취약점이 있는지 찾는 행위가 매우 힘들어서 백업 파일들이나 개발자들이 만들어놨던 파일들을 찾아서 어떤 취약점이 있는지 찾는 루트로 가신다고 함. 예로 관리자 계정, 테스트 계정 등을 적어놓는  기업도 있었고, 관리자 페이지의 소스코드들을 명시놓아서 노다지가 따로없다고하심. 툴에서는 이러한 소스코드 노출의 위험도를 인포메이션인 미비한 정도라고 하지만 스노우볼을 굴리기 매우매우 좋아서 위험함.

 

 

 

 

 

 

sql 관련

 

당연하지만 서버에서 사용하는 db의 종류를 알아야함, db마다 sql 문이 다르니 ㅇㅇ

dos 공격처럼 db를 마비시키는 sql 공격을 많이함, 슬로우리스 공격은 웹서버는 살려도 계속해서 디비요청을 보내 디비를 죽이는 공격임.

blind sql injection은 어렵지만 티는 안나는 공격, 숫자야구마냥 한자리씩 꺼내서 맞추는 공격임

실무에서 취약점 점검을 할 때 웹서버에 간혈적으로 지연 현상이 있는데 이 때 블라인드 에스큐엘 인젝션을 하고 있을 가능성이 있음.

sql 인젝션이 가능한지는 버트 스위트에서 파라미터 요청에 컴마를 하나 찍어보고 에러메시지를 확인하며 가능 유무를 판단함.

이렇게 쉬운 행위를 해보는 이유는 간혹가다가 클라이언트 단에서 검증을 하지만 서버단에서는 검증을 안하는 곳도 있었기 때문.

sql 공격은 따지고보면 db공격이지만, db에 가는 길은 웹 서비스 밖에 없으니 웹공격으로 판단한다 하심.

union을 이용한 공격이 효율이 매우 좋아서 union에 대한 필터링은 뺴먹지말고 꼭 걸어야한다함.

필터링을 우회하는 방법들은 여러가지가 잇는데, 주석을 사용하거나, char 함수를 이용해서 숫자를 문자로 바꾸는식으로 우회하거나, 16진수에서 문자로 변경하는 식으로 하는데 무조건 막혀있음.

sql 인젝션을 쉽게 방어하려면 입력 폼에 최대 받는 글자 수를 20자 정도로 제한하여 필터링 우회도 어렵고 복잡한 공격하기도 어렵게하여 한정적인 공격만 가능하게해 막는다고함.

 

 

실무 관련 2 

실무에서는 기업이 자주 사용하는 메인시스템들은 보안들이 잘 되어있기 때문에 잘 안뚫려서 잘 사용하지 않는 관리가 잘 되지 않았던 낙후되있는 사이트들을 주로 점검한다고하심.

같은 서버에서 버츄얼 호스트로 분리가 되어있는 경우가 많아서 b라는 낙후된 웹 서비스에 공격을 성공하면 메인 서비스인 a에도 영향을 끼칠 수 있음.

 

 

 

파일 다운로드 취약점 관련

 

/etc/passwd를 취약점 점검에서 이 사이트 뚫었다는 표시로 보여주는데 그냥 비밀번호가 보인다는 내용이 일반인들에겐 경각심을 주기 좋아서 사용하는거고 사실 config파일인 설정파일들을 가져오는게 공격에 효율적임. 웹서버의 구조나 데이터베이스에 연결하기 위한 이이디 비번 포트들을 전부다 알 수 있기 때문임. 

주요 취약점 발생위치는 게시판의 첨부파일 다운로드, 텍스트 파일 내용 미리보기, 사진파일 다운로드 또는 미리보기임.

위 같은 행위들을 할 때 웹프록시를 걸어놔서 다운로드 경로를 /etc/passwd로 바꾸어 파일 다운로드 취약점을 일으킴

우회 방식은 유니코드형식으로 인코딩하여 우회하는 방법도 있음. 포맷스트링도 있고 base64로도 해보고 아무튼 인코딩은 웹방화벽을 우회하는 좋은 수단을 제공함.

 

 

파일 업로드 취약점 관련

 

당연한 말이지만 글 쓰기 뿐만아니라 글 수정시에도 확장자 필터링이 필요함.

파일 업로드 취약점이 강력한 이유는 웹쉘을 서버에 올릴 수 있어서 위험한데, 업로드에 성공하여도 웹쉘을 실행을 시켜야하는 행위를 해야하는데 파일 다운로드 취약점으로 경로를 알고 실행을 시킬 수 있어 짝으로 쓰인다고 하심.

클라이언트, 서버 사이드 둘다 필터링을 걸어야하고, 굳이 하나만 걸어야한다면 서버에는 무조건 걸어야함. (당연한 이야기지만)

서버측에서는 확장자를 화이트리스트나 블랙리스트로 필터링을하고 대소문자 조합의 확장자 우회 실행 확장자 변경 Null 문자나 공백문자 등으로 우회를 시도한다고 함.

파일 헤더를 검사하여 특정파일의 시그니쳐가 존재하는 경우에만 업로드를 허용하는데 업로드 되는 파일의 헤더 조작해서 필터링을 우회하기도 한다고함. (군대에서 발견했던 취약점)

 

 

 

 

쿠키, 세션 관련

 

쿠키는 데이터 위조하기 쉬움, 쿠키로 인증을 한다면 값만 바꾸고 게시판 등에서 권한이 없는 글쓰기 또는 수정 글읽기 가능.

그리고 사이트에서 어드민 페이지나 권한이 필요한 페이지들의 url을 추측할 수 있게 네이밍을 해놓으면 안되기 때문에 가능하면 무작위 문자열로 해놓는게 좋긴함. 물론 권한검사를 제대로하면 노상관임.

과거에는 패스워드 변경 페이지에서 현재 패스워드를 검사하지않아, 웹 프록시를 이용하여 사용자 id를 교체하고 원하는 id에 비밀번호를 변경하여 로그인이 가능하던 시기가 있었음.

sso인증은 초기에는 세션하이제킹이 쉬워서 요즘에 타임스탬프나 대칭키 암호방식으로 암호화도 하고 보완을 하였음.

 

 

 

 

아무튼 가장 중요한것은 정보수집단계가 가장 중요하다고 하심.

어떤 디비를 쓰는지 백엔드의 언어가 무엇인지 소스코드가 유출되어 있는지 등등 강의를 들어보니 공감을 할 수 있었음.

 

또한 owasp zap과 burp suite도 잘 사용할 수 있게되어서 좋은 시간이였던거 같음.

 

2일차는 나중에 이어서 써야겠다.