후기(?)
sechack여친구함 팀에서 CTF를 진행하게 되었고 버스 탄 덕분에 1등을 하게 되었다....
워게임 풀 때는 맨날 웹만 푸니까 체감을 못했는데 웹 원툴의 무력함을 제대로 느끼게된 계기였다.
웹 문제에서 막히니까 다른 부분은 손도 못대고.....
CTF 기간 내 푼 문제와 이후에 푼 문제를 적어보겠다.
Write-Up
TOP SECRET(WEB)
해킹캠프 23회를 위해 참가자들을 환영하는 페이지를 만들었어요 ~~
그런데 누군가 관리자 계정을 탈취하였고 이를 통해 디페이스 공격을하여 페이지를 변경시켜버렸어요 ㅠㅠ
홈페이지에 해커가 남긴 문구를 통해 해커의 계정을 찾고 접속하여 숨겨진 메시지를 볼 수 있나요?
먼저 회원가입 페이지가 보이길래 테스트 계정을 생성하여 로그인을 시도해보았다.
그러면 유저 페이지에 접속할 수 있다.
여기서 주의 깊게 보아야할 것은 아래 부분에 해커가 삽입한 문구이다.
hacked by hackingcamp@hackingcamp.org
이것을 보면 해킹을 시도한 유저의 계정은 hackingcamp임을 추리해 볼 수 있다. 나는 이 부분을 캐치하지 못하고 admin계정을 공격하고 계정에 접근하고 플래그가 없어서 매우 당황했었다.
다시 문제 풀이로 들어가보면 첫 접근은 기존에 있는 sql injection을 통해 공격하는 것이라고 판단하여 id,pw를 계속 공격하였지만 답이 나오지 않았습니다.
그리고 시간이 지나 첫 번째 힌트 admin account takeover라는 힌트가 나오게 되고 그 것을 보자마자 생각나는 취약점이 한 가지 생각이 났다.
이 취약점은 CVE-2020-22784로 알려져있다.
이 취약점을 이용해서 공격하는 방법은 id 파라미터로 전달되는 값을 공격하고 싶은 계정의 id값 앞뒤로 leading/trailing white space를 이용하여 회원가입하고 로그인을 한다.
로그인을 한 후 비밀번호를 변경하는데 이 때 비밀번호가 변경되는 계정으로 넘어가는 값은 원래 전달받은 id값에서 leading/trailing white space를 제거하여 남은 값, 즉 공격하고 싶은 계정의 id 값이 넘어가게 된다.
따라서 이 취약점을 이용해 비밀번호를 변경하게 되면 탈취하고 싶은 계정의 비밀번호를 성공적으로 변경할 수 있게 된다.
이에 따라서 실제로 공격하게 되면
공격할 id 앞뒤로 leading/trailing white space를 이용하여 회원가입을 해줍니다.
그리고 그 계정으로 로그인하여 비밀번호를 바꿉니다.
이렇게 비밀번호를 1로 변경하면 기존 가입했던 hackingcamp 가 아닌 hackingcamp 의 아이디가 변경되게 된다.
따라서 성공적으로 탈취한 계정에 로그인 하면 플래그 값을 찾을 수 있게 된다.
ps) 참고로 위에서 말했지만 문제가 조금 애매해서 처음 5시간 가량은 admin 계정을 계속 공격하였다...
알고보니까 내가 공격한 admin은 다른 CTF 참가자가 만든 테스트 계정이였다...
그 분에게 강태공의 기질이 보인다....
해킹 멈춰!!(WEB)
이 문제는 개인적으로 CTF 서버를 관리하셨던 DEMON 팀원 분에게 많이 죄송했던 문제이다... 나중에 설명하겠지만 접속 가능한 특정 ip를 찾는 과정에서 브루트포싱을 이용하여 공격을 시도하였다.... 동시에 많은 공격이 글어가니까 바로 서버에서 500을 반환해서 바로 취소하기는 했지만... 죄송합니다.. (아니 근데 문제가 좀 그랬어요...)
저희 공장 서버가 해킹을 당했습니다 ㅠㅠ
들어가면 봇이 탐지되었다며 접근이 안돼요
원래 정말 봇을 탐지하려고 만들었던 기능인데 아마 해커가 서버 코드를 조작한 것 같습니다.돈이 없어서 데이터베이스도, 웹서버도 다 하나로 관리하다보니 아무것도 할수가 없어요 ㅠㅠ
부디 도와주세요!
관리자 로그인페이지에서 사용가능한 비밀번호는djenadls~?입니다!
이 문제를 처음 들어가게 되면 이런 페이지가 우리를 반겨준다.
그리고 이어서 우측 상단에 Detected Result null이라는 초록색 창이 뜨고
검출 결과에 따라 페이지를 보여주는 방식으로 이루어져있다.
이 과정을 구체적으로 확인해 보게 되면
이런 3가지 과정을 통해 봇 검출을 한다고 볼 수 있다.
이 중에서 우리가 유심히 봐야할 것은 /api/bot_check 부분이다.
이 부분에서의 리턴값에 따라 사이트에서 봇을 판정하는 것 같다.
여기서 한 가지를 생각해 볼 수 있다.
해커가 공격을 통해 정상적인 연결도 봇으러 감지되게 만들었다면 과연 어떤 방식을 통해 봇 검출 시스템을 무력화시킨 것일까??
당장 생각나는건 2가지이다.
첫째, 모든 연결을 추가적인 검증 없이 모두 봇으로 인식하게 만드는 것이다.
그런데 이렇게 만들었다고 가정하면 문제를 해결할 수 없기에 이 가정은 틀렸다고 확신했다.
두번째, 봇이랑 일반사용자에 따른 각각의 반환 값에 해당하는 함수의 결과를 반전시키는 것이다. 이러면 원래 봇으로 검출되는 값만 발견하면 문제 진행이 가능하므로 이 가설이 진실이라고 생각하고 문제를 풀었다.
마지막 결과 페이지를 보면 뭔가 너무 크게 보여주는 값이 있는데 바로 User-Agent 해더 값이다.
이 해더는 유저가 사용 중인 브라우저의 종류를 알려주는 해더인데 뭔가 봇 검출할 때 쓰이는 값일 수도 있다는 생각이 들어 sql injection을 시도하였다.
리피터로 넘겨 User-Agent에 sql injection을 시도해보니
이런 Response가 도착했다. 따라서 우리는 Super Hacking Camp Bot이 원래 페이지에서 막으려했던 봇임을 알게 되었다. 이대로 값을 보내도 진행이 되겠지만, 한 번 직접 User-Agent에 Super Hacking Camp Bot을 입력시켜 진행해보겠다.
Super Hacking Camp Bot이라고 뜨면서 성공적으로 Admin Login 페이지로 넘어가게 된다.
이때 Admin Page의 비밀번호는 문제에서 djenadls~?라고 알려주었기 때문에 로그인하면 flag를 얻고 끝날줄 알았다...(문제가 EASY여서 방심했다..)
하지만 정작 비밀번호로 로그인을 시도하면
이런 어이없는 문구에 직면하게된다.
이 문구를 접한 저를 비롯한 팀원들은 X-Forwarded-For 해더를 사용해서 해결해야한다고 판단, 바로 ip를 찾는 작업에 착수했다.
처음에는 insert 구문으로 걍 우리 ip를 허용 목록에 집어넣자는 의견이 나왔지만 일단 화이트 리스트 기반인지 확실지 않고(맨 처음은 MySQL 계정 생성할때 로그인 허용할 ip로 막는 줄 알았다.) 무슨 테이블에 어떤 동작으로 로그인을 차단하는지 확실하지 않아 첫번째 의견은 보류하기로했다.
그리고 시간이 지난 후 힌트가 오게 되고 화이트 리스트 기반의 차단 방식이 확실해지게 되고 기존에 이용했던 User-Agent를 다시 이용하는 것이라는 힌트를 받았을때 UNION구문을 이용하며 공격을 수행했으나 계속 오류가 나면서 공격이 실패를 해서 결국 대회가 종료될 때까지 풀지 못하였다.
CTF 서버가 1주일 공부용으로 재오픈 되었을때 가장 먼저 이 쪽을 다시 공격해보았습니다. 기본적인 문법은 작동을 하는데 INFORMATION_SCHEMA에 접근하려고하면 계속 오류를 출력하길래 차분히 생각을 해보았다.
그 순간 설마하면서 version()을 입력했으나 오류가 발생하였다...
설마가 현실이 된 것이다...
이 문제의 DBMS는 MySQL이 아니였던 것이다.....
다른 문제의 DBMS가 모조리 MySQL이였어서 확인도 하지않고 지레짐작 넘어간 것이였다.
MySQL이 아니니 당연히 INFORMATION_SCHEMA에 접근하려고 하면 없는 DB이므로 오류가 발생했던 것이다...
그래서 빨리 DBMS 특정을 하려고 시도를 하였고 결국 사용 중인 DBMS가 SQLite인것을 알았다...
하지만 한 번도 SQLite를 이용하는 문제는 풀어본 경험이 없어 바로 구글링을 통해 기본적인 정보를 수집했다.
SQLite는 테이블 명을 sqlite_master에 존재하는 tbl_name에 저장한다는 것을 알게되고
1" union select tbl_name from sqlite_master limit 0,1 --
1" union select tbl_name from sqlite_master limit 1,1 --
1" union select tbl_name from sqlite_master limit 2,1 --위 코드로 User-Agent 에 인젝션을 시도해보면 존재하는 테이블 명은 bot, user, white_list가 있음을 알 수 있다.
딱봐도 white_list를 살펴보면 접속 허용된 ip를 볼 수 있을 거 같으므로
1" union select ip from white_list-- 를 이용하여 쿼리를 조작하면 접속 가능 ip인 19.98.12.18가 나오게 된다.
따라서 X-Forwarded-For 해더를 이용하여 ip를 변조 후 request를 보내게 되면
플래그를 성공적으로 가져올 수 있다.
ps) 잘못된 DBMS를 사용 중이라 추정해 모든 공격에 오류가 발생하자 너무 화가 나서 사람이 대부분 다 자러간 새벽 5시 반부터 0.0.0.0부터 255.255.255.255의 모든 ipv4 값을 브루트포싱 공격을 시도했으나 5분만에 서버가 버티지 못하고 죽어버렸고 다른 참가자가 운영진분에게 500 뜬다고 문의 넣은걸 보고 바로 포기했다. 단순 계산만 해도 대략 42억번 공격을 해야하니까 솔직히 말이 안되는 짓이긴 했다... 반성하고 있습니다 ㅋㅋㅋ
World Wide Web(WEB)
World Wide Web
플래그 경로는 /tmp/flag 에 있습니다.
이 문제의 설명을 보면 플래그의 경로를 알려주고 있다. 여기서 바로 LFI 취약점을 이용하는 문제인것을 유추할 수 있다.
문제 페이지에 점속해보면 이런 화면이 보인다.
소스 코드를 확인해보면 <img>태그에 alt값을 보면 /phpMyAdmin를 사용하는 것을 볼 수 있다.
따라서 /phpMyAdmin으로 접근해보겠다.
접근하면 로그인 페이지가 나타나는데 계정에 관한 정보가 없다...
막혔을때 뭐라도 건지려면 소스코드를 봐야한다는 경험을 기반으로 소스코드를 보았고 다행이 계정 정보가 hidden태그로 숨어있었다.
따라서 주어진 계정 id : wwwweb, pw : wwwweb!@#으로 로그인을 시도하면 성공적으로 로그인이 된다.
여기서 바로 phpMyAdmin의 버전을 확인해보면
4.8.1인것을 알 수 있다.
지금까지 알아내거나 유추한 정보를 모두 모아보면
phpMyAdmin 4.8.1을 사용하고 있는 웹에서 LFI 공격을 이용하여 /tmp/flag에 존재하는 플래그를 확인해야한다이렇게 알 수 있다.
따라서 목표는 명확해졌으므로 구글링을 시작해보면 phpMyAdmin 4.8.1 버전에 LFI 취약점이 존재하는 것을 알 수 있다.
이러면 LFI를 이용하는 것도 확실해졌으니까 CVE-2018-12613를 참조하여 취약점을 분석하여 공격을 진행하였다.
http://ctf-hackingcamp.com:60698/phpMyAdmin/index.php?target=server_sql.php?%253f../../../../../../tmp/flag위와 같은 방법으로 공격을 시도하였더니 플래그 값을 얻을 수 있었다.
ps) CVE-2018-12613는 나중에 한번 제대로 분석해봐야겠다.
