소개

웹 앱에는 취약점은 있지만, Moodle에도 때때로 중대한 취약성이 발견된다. 실제로 이 취약점을 이용하여 Moodle 사이트를 공격해 본다.
그리고 다음 번에는 방어 방법을 생각한다.

팁

이 메모를 시도할 때는 반드시 자신이 관리하는 Moodle 사이트에서 할 것. 여러가지 중요한 것을 잃을 가능성이 있나요?

CVE-2017-2641 정보

개요

CVE-2017-2641은 Moodle 3.2.1 이전에 존재하는 SQL 주입 공격으로 사용자 환경 설정 기능의 취약점을 이용합니다.
Moodle 공식 사이트 에도 기재가 있어, commit diff 확인 그러면 unserialize()에 유저 입력을 건네주는 것이 문제점이라고 보여진다.

실증 코드 (PoC)

일부러 붙이지 않지만, 구그하면 PoC가 발견되므로, 그것을 사용해 시험해 본다. 시도한 PoC에서는 DB를 갱신시키기 위한 오브젝트를 작성해 serialize한 것을 JSON으로 해 POST하고 있다.
여기서 공격에 필요한 것은 다음과 같다.

공격 대상 Moodle 사이트의 사용자 계정

로그인시 쿠키의 MoodleSession 값

로그인시 Moodle sesskey 값

로그인 사용자의 사용자 ID

이 PoC에서는 런타임에 사용자 환경 설정 페이지에 액세스 할 필요가 있기 때문에 게스트 사용자는 공격을 할 수 없습니다. 또, 이용하고 있는 update_user_preferences()가 Moodle 3.2 이후 밖에 존재하지 않기 때문에, Moodle 3.1.x 이전에서는 이 PoC는 동작하지 않는 것 같다. 따라서 Moodle 3.2 (.0) 및 3.2.1이 적용됩니다.
이 PoC에서는 "임의 테이블의 임의의 필드를 행 id를 지정하여 갱신하는"가 가능하다는 것을 나타내고 있으며, 실제로 PoC에서는 config 테이블의 사이트 관리자의 ID를 지정하고 하는 행을 SQL 인젝션으로 갱신해, 지정한 유저 ID를 가지는 유저를 사이트 관리자로서 하고 있다.
설치시의 설정에 따라서는 테이블명에 mdl_라든가 프리픽스가 붙어 있는 일이 있지만, Moodle측에서 마음대로 보완해 주기 때문에 모르더라도 안심♪

실제로 공격해 본다

타겟 사이트 준비

과거 기사에 따라 Moodle 3.2 사이트를 구축하고 여기에 "사이트 관리자"와 "일반 사용자"라는 두 개의 계정을 만듭니다.

사전 준비

일반 사용자로 로그인합니다.


헤더 정보로부터 MoodleSession의 값을 조사한다.


사용자 ID를 검사한다.


sesskey의 값을 조사한다.

PoC 실행

이러한 값을 이용하여 PoC를 실행한다. 실행하면 다음 값이 정상 값 대신 전송됩니다.

a:2:{i:0;a:1:{i:0;O:29:"gradereport_overview_external":0:{}}i:1;O:40:"gradereport_singleview\local\ui\feedback":1:{s:5:"grade";O:11:"grade_grade":1:{s:10:"grade_item";O:10:"grade_item":6:{s:11:"calculation";s:12:"[[somestring";s:22:"calculation_normalized";b:0;s:5:"table";s:6:"config";s:2:"id";i:25;s:5:"value";i:3;s:15:"required_fields";a:2:{i:0;s:5:"value";i:1;s:2:"id";}}}}}

확인

일단 로그아웃하고 다시 로그인하면 일반 사용자가 사이트 관리자가 된다. (사이트 관리 메뉴가 표시됨)


DB를 확인하면 사이트 관리자의 사용자 ID가 재기록되어 있는 것을 확인할 수 있다. 본래는 2로 되어 ​​있다(1은 게스트 사용자).


대신 관리 사용자로 로그인하면 사이트 관리자로 사라진 것을 알 수 있다.

기타

아래와 같이 지정하면 Moodle 사이트의 longname를 재기록할 수 있다.

$table = 'course';
$rowId = 1;
$column = 'fullname';
$value = 'ALL YOUR MOODLE ARE BELONG TO US!';

설명 메모

이 블로그 의 Part3까지로 이 취약성으로 SQL 인젝션 공격을 할 수 있는 설명이 되어 있다.
그러나 이번 PoC에서 필요한 행 ID가 필요한 문제에 대해 Part4에서 검토하고 있는 점이 다르다.