ความสำคัญของการอัพเดตซอฟต์แวร์ให้ทันสมัยอยู่เสมอ – กรณีศึกษาช่องโหว่ของ Themegrill Demo Importer บนเว็บที่ใช้ WordPress

เมื่อวานนี้ มีเว็บไซต์ที่ใช้ WordPress และติดตั้งธีมจาก Themegrill จำนวนมากทั่วโลก เจอปัญหาว่าเปิดเว็บมาแล้วกลายเป็นเว็บหน้าแรกสุดสมัยติดตั้ง WordPress ใหม่ๆ เลย ขึ้นมาก็ Hello world สวัสดีชาวโลก ซะงั้น ไล่เรียงไปๆ มาๆ พบว่า มันเกิดจากช่องโหว่ของปลั๊กอินชื่อ Demo Importer ของ Themegrill ที่เอาไว้ดึงข้อมูลเดโมมาใช้ เพื่อจะได้เซ็ตค่าต่างๆ ของเว็บไซต์ได้รวดเร็วขึ้น แต่เพราะช่องโหว่นี้แหละ ส่งผลให้คาดว่ามีเว็บเป็นแสนๆ เว็บที่ได้รับผลกระทบ และผลกระทบที่ว่า ก็คือการที่ฐานข้อมูลโดนล้างทิ้งหมด เว็บกลับไปเป็นเหมือนตอนติดตั้งใหม่ๆ เลย

คำถามมีอยู่ว่า เราจะไม่มีทางป้องกันอะไรแบบนี้ได้เลยเหรอ? คำตอบคือ เรามีทางป้องกันครับ แค่ว่าหลายๆ คน มักจะมองข้ามเรื่องนี้ไปเท่านั้นเอง

ช่องโหว่ของซอฟต์แวร์ ช่องทางของการแฮก

ถ้าเราจะจัดประเภทของการแฮก มันมีวิธีจัดได้หลายแบบ แต่ในกรณีการแฮกเว็บไซต์นี้ผมขอแยกประเภทของการแฮกเป็นสองประเภทใหญ่ๆ คือ

• แฮกเพื่อเป้าหมายบางอย่างโดยเฉพาะ เช่น การเข้าไปแก้ไขข้อมูลในฐานข้อมูล การขโมยข้อมูล อะไรพวกนี้
• แฮกแบบไม่เลือกเป้าหมาย โดยมากจะเป็นแค่การเปลี่ยนหน้าเว็บไซต์ (Deface) หรือลบข้อมูลทิ้งบางส่วนหรือทั้งหมด ตามแต่ว่าช่องโหว่เอื้อให้แค่ไหน

ซึ่งกรณีของช่องโหว่ Demo Importer บน Themegrill เป็นแบบที่สองครับ คือ แฮกเกอร์เขียนสคริปต์ขึ้นมา อาศัยช่องโหว่ของปลั๊กอิน แล้วยิงใส่เว็บไซต์ต่างๆ ที่มีช่องโหว่นี้เพื่อลบฐานข้อมูลของเว็บไซต์พวกนี้ทั้งหมด

แต่บนพื้นฐานด้าน Computer security แล้ว หากเราพบว่าแฮกเกอร์มีการเข้าถึงเว็บไซต์ได้ในระดับที่สั่งลบฐานข้อมูลได้ และเมื่อสืบลึกไปอีกว่าหากแฮกเกอร์สามารถใช้ช่องโหว่นี้ในการเข้าถึงในฐานะผู้ดูแลระบบได้แล้วละก็ ถือว่าเว็บไซต์ถูก Compromised ไปแล้ว จำเป็นต้องมีการเริ่มต้นทำเว็บไซต์ใหม่ หรือ กู้คืนจากแบ็กอัพที่มั่นใจว่าปลอดความเสี่ยง จะมาคิดเข้าข้างตัวเองว่าแฮกเกอร์คงไม่ได้วางบั๊กอะไรไว้อีก หรือไม่ได้มีเจตนาอื่นใดแอบแฝงอีก คิดแบบนี้ไม่ได้เลย

ช่องโหว่ของปลั๊กอิน Demo Importer อยู่ตรงไหน?

ทีม WebARX เป็นผู้ค้นพบช่องโหว่นี้ครับ เขาชี้ให้เห็นถึงข้อผิดพลาดของโค้ดในส่วนของฟังก์ชัน reset_wizard_actions() ซึ่งมีไว้เพื่อรีเซ็ตเว็บทั้งหมดให้กลับไปที่จุดเริ่มต้น เพื่ออำนวยความสะดวกแก่ผู้ที่ต้องการจะเซ็ตอัพเว็บไซต์ใหม่

<?php	
        public function reset_wizard_actions() {
		global $wpdb, $current_user;

		if ( ! empty( $_GET['do_reset_wordpress'] ) ) {

			///

			if ( 'admin' != $current_user->user_login ) {
				$user = get_user_by( 'login', 'admin' );
			}

			if ( empty( $user->user_level ) || $user->user_level < 10 ) {
				$user = $current_user;
			}

			// Drop tables.
			$drop_tables = $wpdb->get_col( sprintf( "SHOW TABLES LIKE '%s%%'", str_replace( '_', '\_', $wpdb->prefix ) ) );
			foreach ( $drop_tables as $table ) {
				$wpdb->query( "DROP TABLE IF EXISTS $table" );
			}

			// Installs the site.
			$result = wp_install( $blogname, $user->user_login, $user->user_email, $blog_public );

			// Updates the user password with a old one.
			$wpdb->update(
				$wpdb->users,
				array(
					'user_pass'           => $user->user_pass,
					'user_activation_key' => '',
				),
				array( 'ID' => $result['user_id'] )
			);

			// Set up the Password change nag.
			$default_password_nag = get_user_option( 'default_password_nag', $result['user_id'] );
			if ( $default_password_nag ) {
				update_user_option( $result['user_id'], 'default_password_nag', false, true );
			}

			///

			// Update the cookies.
			wp_clear_auth_cookie();
			wp_set_auth_cookie( $result['user_id'] );

			// Redirect to demo importer page to display reset success notice.
			wp_safe_redirect( admin_url( 'themes.php?page=demo-importer&browse=all&reset=true' ) );
			exit();
		}
	}
?>

แต่ปัญหาก็คือ เจ้าโค้ดบ้านี่ ที่มีความสามารถอย่างล้นเหลือในการลบฐานข้อมูลทิ้งทั้งหมด ดันไม่มีการตรวจเช็กสิทธิ์ของผู้ใช้งานก่อนที่จะรัน ส่งผลให้แค่มีการส่งค่า do_reset_wordpress ผ่านมาทาง URL ซึ่งก็ไม่ใช่ Payload น่าสงสัยอะไรเลย ส่งผลให้แม้แต่ Firewall ก็บล็อกไม่ได้ และด้วยข้อความง่ายๆ แค่เนี้ย มันก็ทำให้ฟังก์ชันถูกเรียกมาใช้งาน และตารางของ WordPress ทั้งหมดก็โดนลบทิ้งไปโดยปริยาย กลับไปที่ค่าเริ่มต้นใหม่

ซึ่งสำหรับการแก้ไขนั้น WebRAX บอกว่าแค่เพิ่มโค้ดเข้าไปสามบรรทัดแบบนี้ ก็เรียบร้อยแล้ว คือ แค่เพิ่มโค้ดให้มันเช็กสิทธิ์ของผู้ใช้งานก่อนเท่านั้นเอง นี่ผมก็อปปี้โค้ดที่ทาง WebRAX มาให้ดูกัน

<?php

global $wpdb, $current_user;

if (!current_user_can('manage_options')) {
	wp_die(_('Cheatin’ huh?', 'themegrill-demo-importer'));
}

	///

	if ( ! empty( $_GET['do_reset_wordpress'] ) ) {
	    
?>

ช่องโหว่พวกนี้ ป้องกันได้ แค่ต้องใส่ใจ อัพเดตให้ทันสมัยอยู่เสมอ

จริงๆ แล้ว ช่องโหว่นี้ และอีกหลายๆ ช่องโหว่ที่เคยมีมาในอดีต ในทุกๆ ปลั๊กอิน และในทุกๆ ซอฟต์แวร์ มันสามารถป้องกันได้ครับ มันแค่หลายๆ คนไม่ได้ใส่ใจก็เท่านั้นเอง ยกตัวอย่างเคสนี้นะ WebRAX เขาค้นพบช่องโหว่นี้ตั้งแต่วันที่ 6 กุมภาพันธ์ และมีการออก Patch ให้ลูกค้าของ WebRAX ทั้งหมด พร้อมแจ้งปัญหาไปที่ผู้พัฒนา แต่ยังไม่ได้รับคำตอบใดๆ เขาก็เลยมีการแจ้งไปใหม่อีกครั้งวันที่ 11 กุมภาพันธ์ และก็ได้คำตอบมาวันที่ 14 กุมภาพันธ์ ซึ่งทีมงานก็ได้ทำการส่งปัญหาดังกล่าวไปให้อีกครั้ง และวันที่ 16 กุมภาพันธ์ Themegrill ก็ออกอัพเดตมาให้ดาวน์โหลดกัน

แต่ปัญหามันอยู่ตรงนี้ไง คือ บ่อยครั้งที่เวลาพวกคนทำงานด้าน Security เจอช่องโหว่ พวกแฮกเกอร์อาจจะยังไม่เคยเจอช่องโหว่นี้ แต่พอเขาแจ้งไปที่ผู้พัฒนาซอฟต์แวร์ แล้วมันมีการออกอัพเดตเพื่อแก้ไขออกมา พวกแฮกเกอร์มันจะเข้าไปดูตัวอัพเดต เพื่อหาดูว่าช่องโหว่ที่ถูกแก้ไขมันอยู่ตรงไหน แล้วก็จะเขียนสคริปต์ หรือโปรแกรมขึ้นมา เพื่ออาศัยช่องโหว่นั้นในการโจมตีซอฟต์แวร์หรือเว็บไซต์ ฉะนั้น เราจึงมักจะเห็นเว็บไซต์หรือเครื่องคอมพิวเตอร์จำนวนมาก ที่โดนโจมตีหลังจากที่ซอฟต์แวร์มีการออกอัพเดตมาเพื่อแก้ไขช่องโหว่ระดับ Critical (หมายถึงพวกช่องโหว่ที่ส่งผลให้ระบบถูก Compromised ได้)

จริงๆ ทางแก้ก็ไม่ได้ยากเลยครับ แค่เราต้องรู้ว่าเราใช้ซอฟต์แวร์อะไรอยู่บ้าง และหมั่นติดตามข่าวสารจากผู้พัฒนาซอฟต์แวร์ แล้วคอยอัพเดตซอฟต์แวร์ให้ทันสมัยที่สุดเสมอเท่านั้นเอง ซอฟต์แวร์ตัวไหนที่มีความสามารถในการเช็กอัพเดต และอัพเดตตัวเองโดยอัตโนมัติ ก็เปิดใช้งานมันซะ แต่ถ้าใครกังวลว่าการอัพเดตมันอาจจะส่งผลกระทบอื่นตามมา (ซึ่งเป็นไปได้ เพราะมีบ่อยครั้งที่อัพเดตแล้ว มีบั๊กอื่นตามมา) เราก็อาจจะไม่เปิดให้อัพเดตอัตโนมัติ แต่เราก็ควรให้มันแจ้งเตือนเมื่อมีการอัพเดต แล้วเราก็รีบไปดูว่าอัพเดตอะไร มีการอัพเดตช่องโหว่สำคัญไหม ถ้ามี ก็ต้องรีบติดตั้งใจอัพเดต

การแบ็กอัพก็สำคัญมากๆ

และสิ่งที่สำคัญที่สุดคือการแบ็กอัพเอาไว้ วางแผนแบ็กอัพให้ดีๆ เพราะมันคือฟางเส้นสุดท้ายของเรา กรณีที่มันชิบหายแล้ว เราก็ยังพอจะสามารถกู้คืนมาได้อย่างน้อยก็เกือบทั้งหมด หรือ บางส่วน (อยู่ที่ว่าเราแบ็กอัพเอาไว้ดีแค่ไหน) อย่างผมเนี่ย ผมเลือกใช้โฮสต์ของ WordPress.com ซึ่งมีการแบ็กอัพทุกวัน และสามารถย้อนหลังไปได้ 30 วัน ฉะนั้น แม้ผมจะพลาดท่าตกเป็นเหยื่อ ผมก็ยังสามารถติดต่อไปทาง Happiness engineer ของ WordPress.com เพื่อขอกู้ข้อมูลคืนได้ เป็นต้น

การแบ็กอัพ มันช่วยอีกเรื่องคือ ในกรณีที่เรากลัวมีปัญหาจริงๆ และเลือกที่จะอัพเดตโดยอัตโนมัติ โดยยอมเสี่ยงกรณีที่อัพเดตมันไปก่อให้เกิดปัญหาอื่นตามมา เราก็ยังสามารถกู้ระบบกลับมาได้ โดยใช้แบ็กอัพก่อนเวลาที่เราอัพเดตนั่นเอง