경희Talk 취약점 분석기

바르게 살자

 

 한 2월 쯤에 민우랑 같이 경희톡 취약점을 분석했던 적이 있다. 경희톡은 경희대학교 주요 서비스들 중에 가장 취약했었는데, 이제 제보했던 시기도 6개월 정도 흘렀고 취약점도 고쳐진 지 오래라 어떤 식으로 취약점을 분석했고 공격할 수 있었는지 작성해보려고 한다.

 

프로젝트 배경 및 목적 🎈

 경희대학교 학우분들이 애용하는 시간표 관리 및 대학생 커뮤니티 사이트인 ‘에브리타임’(이하 ‘에타’)에서 경희톡에 무분별한 음담패설 및 욕설이 담긴 글에 대한 불만의 글이 학우분들의 공감을 많이 받았다. 

 

 해당 글의 첨부자료에는 아래와 같은 스크린샷이 함께 올라와 있었는데, 다음과 같다.

 계정의 실제 주인이 아니라 악한 의도를 가진 임의의 공격자가 주인을 사칭하여 글을 올린 것이 아닐까라는 생각이 들었다. 그래서 이 가설을 입증하고, 유사한 사건 발생을 방지하며 추후 발생 가능한 사이버 사고에 대한 예방을 목적으로 이 프로젝트를 진행하였다.

 

Vulnerabilities 📡

 

1. User-Id 인증 우회 후 전화번호 등의 개인정보 유출

1. https://talk.khu.ac.kr/web/#/myProfile 에 접속한다.

2. https://talk.khu.ac.kr/rest/user/68005 에 요청을 보내 유저의 정보를 가져오는 것을 확인한다.

3. 요청할 때 보내는 ‘User-Id’ 헤더를 Victim의 User-Id로 수정하고 https://talk.khu.ac.kr/rest/user/{피해자-Id} 에 다시 요청을 보낸다.

4. 원래대로라면 전화번호를 얻을 수 없지만 서버에서 User-Id를 통해 공격자를 피해자로 판단하기 때문에 피해자의 민감한 개인정보를 얻을 수 있다.

 

2. Feed 작성 시 타인 계정 도용

1. 어떠한 그룹에 Feed를 작성할 때는https://talk.khu.ac.kr/rest/feed에 POST로 feedContent(피드 내용), groupIds(그룹ID), userId(유저ID)를 Data영역에 넣은 뒤 요청을 보낸다.

 

2. 만약 groupIds(그룹ID)와 userId(유저ID)를 조작하면 공격자가 원하는 그룹에, 원하는 사람의 계정을 도용하여 Feed를 작성할 수 있다.

 

3. Feed 댓글 작성 시 타인 계정 도용

1. 어떠한 Feed에 댓글을 작성할 때는 https://talk.khu.ac.kr/rest/feed/comment에 POST로 commentContent(댓글 내용), feedId(피드ID), userId(유저ID)를 Data 영역에 넣은 뒤 요청을 보낸다.

 

2. 서버는 userId에 대해 아무런 검증을 거치지 않기 때문에 조작된 userId를 사용하면 타인의 계정으로 댓글을 남기는 것이 가능하다.

 

4. 이미 작성된 게시글을 권한 없는 사용자가 무단 수정

 

1. https://talk.khu.ac.kr/rest/feed에 PUT으로 feedContent(피드 내용), feedId(피드 ID),  groupIds(그룹ID),  userId(유저ID)를 Data 영역에 넣은 뒤 요청을 보낸다

2. 서버는 userId에 대한 검증 절차가 없기 때문에 조작된 userId를 사용하여 기존에 올린 Feed의 내용을 수정할 수 있다.

5. User-Id header의 조작을 통한 관리자 권한 탈취

1. 경희톡(talk.khu.ac.kr)에서의 모든 요청은 ‘User-Id’라는 HTTP Header가 수반된다.

2. 이는 서버에서 사용자의 계정을 판단하기 위해 사용되는데 해당 Header를 조작해도 서버에서는 아무런 여과 과정을 거치지 않기 때문에 공격자가 원하는 사용자로 둔갑할 수 있다.

3. Proxy를 사용해서 HTTP Request를 보낼 때 모든 Request의 ‘User-Id: 67861’을  ‘User-Id: 1’로 치환한다. (User-Id가 1인 사용자는 Administrator 계정으로 서버의 관리자 권한을 가지고 있다.)

4. 이후 서버가 관리자로 인식하므로 관리자 기능을 제약없이 사용할 수 있다.

   

 

6. 검색 부분에서의 SQL Injection을 통한 데이터베이스 누수

1. 상단바에서

   

   해당 아이콘을 클릭하여 멤버를 검색할 수 있는 화면으로 이동한다.

2. 이름에서 `asdf’`를 입력한다.

1. 예상대로 데이터베이스 에러가 뜨는 것을 확인한다.

2. 이름에서 ` asdf’||’asdf `를 입력한다.

3. 서버에러가 뜨지 않은 것을 통해 SQL Injection 공격에 취약한 것을 확인할 수 있다.

4. 이름에 asdf'||(SELECT '1' FROM DUAL WHERE 'asdf'=DBMS_UTILITY.SQLID_TO_SQLHASH((CHR(65)||(SELECT (CASE WHEN (7574=7574) THEN 1 ELSE 0 END) FROM DUAL)||CHR(65))))||' 을 넣어 조회한다.

5. “ORA-13797: invalid SQL Id specified, A1A”라는 값이 리턴되는 상황을 통해 DBMS_UTILITY.SQLID_TO_SQLHASH 함수 내의 subquery가 실행되어 A1A가 반환되는 것을 확인할 수 있다.

6. 이러한 Error message를 이용해서 공격 스크립트를 실행시키면 원하는 데이터베이스에 접근할 수 있다. 아래는 접근 가능한 데이터베이스 목록이다.