27% website bị tấn công thông qua cập nhật tự động của WordPress

Lỗ hổng được mô tả dưới đây có thể cho phép hacker sử dụng chức năng tự động cập nhật mặc định của WordPress để triển khai các phần mềm độc hại lên 27% website WordPress.

27% website bị tấn công thông qua cập nhật tự động của WordPress

Lựa chọn mục tiêu tấn công

Các máy chủ api.wordpress.org có vai trò quan trọng trong WordPress: phát hành bản cập nhật tự động cho các website của WordPress.

  • Mỗi website sẽ gửi yêu cầu để máy chủ api.wordpress.org khoảng 1 lần trong mỗi giờ để kiểm tra các bản cập nhật plugin, giao diện, hay core.
  • Các phản hồi từ máy chủ api.wordpress.org chứa thông tin về bất kỳ phiên bản mới hơn có sẵn, kể cả các plugin, chủ đề hoặc core cần được cập nhật tự động. api.wordpress.org cũng bao gồm một URL để các website tải về và cài đặt các phần mềm được cập nhật.

27% website bị tấn công thông qua cập nhật tự động của WordPress

Một khi máy chủ api.wordpress.org bị ảnh hưởng, có thể cho phép hacker thay thế URL của mình để các website WordPress tải về và cài đặt phần mềm tự động. Điều này giúp cho hacker có thể tấn công vào 1 lượng lớn các website WordPress thông qua cơ chế tự động cập nhật được cung cấp bởi api.wordpress.org.

  • Tất cả đều có thể xảy ra do bản thân WordPress không yêu cầu cơ chế xác thực chữ ký của các phần mềm được cài đặt. Nó sẽ tin tưởng bất cứ URL nào và gói tin nào được cung cấp bởi api.wordpress.org.

27% website bị tấn công thông qua cập nhật tự động của WordPress

Dưới đây là mô tả chi tiết kỹ thuật của lỗ hổng nghiêm trọng này, lỗ hổng mà có thể thỏa hiệp với máy chủ api.wordpress.org. Wordfence đã báo cáo lỗ hổng này cho WordPress thông qua HackerOne. Họ đã vá trong vòng vài giờ sau khi thừa nhận lỗ hổng.

Chi tiết kỹ thuật của lỗ hổng api.wordpress.org

api.wordpress.org có một webhook Github cho phép các nhà phát triền core WordPress đồng bộ code của họ lên repository của wordpress.org SVN. Nó cho phép họ sử dụng GitHub như là 1 kho lưu trữ mã nguồn của họ. Sau đó, khi họ thực hiện commit để thay đổi đến repository, nó sẽ phát hiện ra và truy cập vào URL trên api.wordpress.org, sau đó có một quá trình xảy ra trên api.wordpress.org thêm code mới nhất vào GitHub.

URL GitHub liên lạc trên api.wordpress.org được gọi là một ‘webhook’ và được viết bằng PHP. PHP cho webhook này là mã nguồn mở và có thể được tìm thấy trong repository này. Chúng tôi đã phân tích code này và tìm thấy một lỗ hổng có thể cho phép kẻ tấn công thực thi mã riêng của họ trên api.wordpress.org và được truy cập vào api.wordpress.org. Đây được gọi là một lỗ hổng thực thi mã từ xa hoặc RCE.

Khi có 1 yêu cầu gửi đến api.wordpress.org, có lẽ là từ GitHub, các webhook api.wordpress.org thực hiện xác minh GitHub với api.wordpress.org bằng việc sử dụng 1 khóa chia sẻ trước và 1 thuật toán băm SHA1. Nó thực hiện như sau:

  • GitHub sẽ gửi đến api.wordpress.org một yêu cầu. Yêu cầu đó:
    • Dữ liệu về GitHub được mã hóa bằng khóa chia sẻ trước, sau đó được cho qua hàm băm bởi 1 thuật toán băm SHA1, cho ra 1 giá trị băm.
    • Giá trị băm đó cùng với dữ liệu JSON được gửi đến cho api.wordpress.org.
  • api.wordpress.org nhận được yêu cầu từ GitHub, bao gồm dữ liệu JSON và 1 giá trị băm. Nó thực hiện:
    • So sánh giá trị băm của nó với giá trị băm mà nhận được từ GitHub, nếu giống nhau, GitHub được xác thực, bởi chỉ có GitHub mới có khóa chia sẻ trước, và chứng minh được có quyền thực hiện các hành động đưa ra trong yêu cầu.

GitHub sử dụng SHA1 để tạo ra hàm băm và cung cấp chữ ký trong 1 tiêu đề: X-Hub-Signature: sha1={hash}. Lỗ hổng ở đây nằm trong việc thực tế code sẽ sử dụng hàm băm được cung cấp bởi khách hàng, thường là GitHub. Điều đó có nghĩa rằng, cho dù đó là GitHub hoặc hacker, họ đều có thể biết được thuật toán băm.

function verify_github_signature() {
	if ( empty( $_SERVER['HTTP_X_HUB_SIGNATURE'] ) )
		return false;

	list( $algo, $hash ) = explode( '=', $_SERVER['HTTP_X_HUB_SIGNATURE'], 2 );

	// Todo? Doesn't handle standard $_POST, only application/json
	$hmac = hash_hmac( $algo, file_get_contents('php://input' ), FEATURE_PLUGIN_GH_SYNC_SECRET );

	return $hash === $hmac;
}

Nếu hacker có thể bỏ qua các cơ chế xác thực webhook, có một tham số POST cho phép họ thực hiện các lệnh shell trên api.wordpress.org. Điều này cho phép họ thỏa hiệp máy chủ. Các cuộc gọi shell_exec có thể được thấy trong đoạn code bên dưới:

$repo_name = $_POST['repository']['full_name'];
$repo_url  = $_POST['repository']['git_url'];

if ( ! $this->verify_valid_plugin( $repo_name ) ) {
	die( 'Sorry, This Github repo is not configured for WordPress.org Plugins SVN Github Sync. Please contact us.' );
}

$svn_directory = $this->whitelisted_repos[ $repo_name ];

$this->process_github_to_svn( $repo_url, $svn_directory );

 

function process_github_to_svn( $github_url, $svn_directory ) {

	putenv( 'PHP_SVN_USER=' . FEATURE_PLUGIN_GH_SYNC_USER );
	putenv( 'PHP_SVN_PASSWORD=' . FEATURE_PLUGIN_GH_SYNC_PASS );

	echo shell_exec( __DIR__ . "/feature-plugins.sh $github_url $svn_directory 2>&1" );

	putenv( 'PHP_SVN_USER' );
	putenv( 'PHP_SVN_PASSWORD' );
}

Thách thức ở đây là bằng cách nào đó đánh lừa các webhook nghĩ rằng họ biết được khóa bí mật chia sẻ trước mà GitHub biết.

Webhook cho phép khách hàng lựa chọn thuật toán băm. PHP cung cấp một số chức năng băm phi mã hóa an toàn như crc32, fnv32 adler32.Những hàm băm là tổng kiểm tra được thiết kế để bắt lỗi truyền dữ liệu và được đánh giá hiệu quả cao với đầu vào lớn, nó không được thiết kế để cung cấp bảo mật.

Nếu hacker có thể tìm thấy một thuật toán băm đủ yếu, nó cho phép chúng tấn công brute force các webhook. Hacker chỉ cần gửi một loạt các giá trị băm cho đến khi api.wordpress.org cho phép các yêu cầu.

Khi webhook cho phép các yêu cầu, các cuộc tấn công thực thi một lệnh shell trên api.wordpress.org cho phép họ truy cập vào các hệ điều hành cơ bản và api.wordpress.org bị thỏa hiệp.

Từ đó hacker có thể hình dung tạo ra bản cập nhật của mình cho tất cả các trang web WordPress, phân phối một backdoor và mã độc hại khác cho các Website. Họ cũng sẽ có thể vô hiệu hóa chức năng tự động cập nhật, khiến các đội WordPress mất khả năng triển khai một bản vá đến các website bị ảnh hưởng.

Điểm CVSS (hệ thống đánh giá lỗ hổng bảo mật) cho lỗ hổng này là:

Wordfence báo cáo lỗ hổng bảo mật này vào ngày 2 tháng 9 và WordPress đã đưa 1 bản vá lên repository ngày 7 tháng 9.

Wordfence đã nỗ lực để có thể thảo luận với các thành viên của đội ngũ an ninh Automattic về nâng cao độ an ninh của hệ thống cập nhật tự động, nhưng vẫn chưa nhận được phản hồi.

Bắt đầu từ ba năm trước đây, đã có một số cuộc thảo luận về việc cung cấp một cơ chế xác thực cho code mà các máy chủ WordPress phân phối, nhưng cho đến nay vẫn chưa có sự tiến bộ.

  • 2016/09/02 21:08 (-0400) – Báo cáo ban đầu gửi lên Automattic thông qua HackerOne.
  • 2016/09/06 19:48 (-0400) – Automattic thừa nhận báo cáo.
  • 2016/09/07 02:02 (-0400) – Một bản vá cho lỗ hổng được đẩy vào repository.
  • 2016/09/21 17:17 (-0400) – Báo cáo được giải quyết và đóng lại.
  • 2016/10/29 05:21 (-0400) – Automattic trao thưởng cho Matt Barry.
    • Matt Barry đã phát hiện ra báo cáo lỗ hổng này.
  • 2016/11/22 – Công khai lỗ hổng.

wordfence