ช่องโหว่ช่องโหว่ของ WordPress REST API ดำเนินต่อไป

เป็นเวลาเกือบสองสัปดาห์แล้วที่ทีมรักษาความปลอดภัยของ WordPress เปิดเผยช่องโหว่ในการยกระดับสิทธิ์ที่ไม่ผ่านการตรวจสอบสิทธิ์ในจุดปลาย REST API ใน 4.7 และ 4.7.1 ช่องโหว่ได้รับการแก้ไขอย่างเงียบ ๆ และการเปิดเผยล่าช้าเป็นเวลาหนึ่งสัปดาห์เพื่อให้เจ้าของเว็บไซต์ WordPress สามารถเริ่มต้นในการอัปเดตเป็น 4.7.2 เมื่อสัปดาห์ที่แล้ว ไซต์ที่มีช่องโหว่หลายแสนแห่งได้ถูกทำลายไปแล้ว และรายงานความเสียหายยังคงดำเนินต่อไป

ในช่วงสุดสัปดาห์การโจมตีเพิ่มขึ้นและบริษัทรักษาความปลอดภัย WordPress ได้เห็นความพยายามมากขึ้นที่ถูกบล็อกโดยไฟร์วอลล์ของพวกเขา Sucuri บริษัทรักษาความปลอดภัยเว็บไซต์ที่รายงานช่องโหว่ของ WordPress กำลังติดตามแคมเปญ “Hacked by w4l3XzY3” เมื่อสัปดาห์ที่แล้วและมีข้อบกพร่องประมาณ 66,000 รายการ แคมเปญนั้นได้ผ่าน 260,000 หน้าที่จัดทำดัชนีโดย Google แล้ว เป็นหนึ่งในเกือบสองโหลของแคมเปญ defacement ที่กำหนดเป้าหมายไปยังช่องโหว่

“ในช่วง 24 ชั่วโมงที่ผ่านมา เราได้เห็นการเติบโตเฉลี่ยของหน้าที่เสียหายต่อแคมเปญที่ 44%” Mark Maunder ซีอีโอของ Wordfence กล่าวเมื่อวันศุกร์ “จำนวนหน้าที่ถูกลบเลือนทั้งหมดสำหรับแคมเปญเหล่านี้ทั้งหมด ตามที่จัดทำดัชนีโดย Google เพิ่มขึ้นจาก 1,496,020 เป็น 1,893,690 นั่นคือการเพิ่มขึ้น 26% ของหน้าที่เสียหายทั้งหมดในเวลาเพียง 24 ชั่วโมง”

Maunder อ้างถึงแผนภูมิ Google Trends ซึ่งเขากล่าวว่าแสดงให้เห็นถึงความสำเร็จของแคมเปญ Defacement ในช่วงสัปดาห์ที่ผ่านมา การขัดขวางเริ่มขึ้นในวันที่ WordPress เปิดเผยช่องโหว่

อย่างไรก็ตาม White Fir Design ซึ่งเป็นบริษัทอื่นที่ให้บริการด้านความปลอดภัย โต้แย้งคำกล่าวอ้างของ Wordfence ว่ามีการแฮ็กเพจ 1.8 ล้านหน้า ตัวเลขประมาณ 2 ล้านหน้าถูกอ้างถึงในรายงานจาก BBC, The Enquirer, Ars Technica, CIO.com และสื่อสิ่งพิมพ์อื่นๆ การออกแบบ White Fir ยืนยันว่าหน้าที่ถูกแฮ็กซึ่งได้รับการจัดทำดัชนีโดย Google นั้นไม่ใช่การนำเสนอที่ถูกต้อง

Sucuri CTO Daniel Cid ยังไม่เห็นด้วยกับการประเมินสถานการณ์ของ Wordfence อย่างเต็มที่ หลังจากทำการวิจัยในช่วงสุดสัปดาห์ที่ผ่านมา Sucuri ประมาณการไซต์มากกว่า 50,000 แห่งที่ถูกแฮ็กโดยมีหน้าเว็บ 20-30 หน้าต่อไซต์ ซึ่งจะอยู่ที่ประมาณหนึ่งล้านจากจุดต่ำสุดของการประมาณการและอยู่ในช่วงถึง 1.5 ล้าน

Sucuri เริ่มเห็นความพยายามที่รุนแรงมากขึ้นในช่องโหว่ REST API ในรูปแบบของการโจมตีการเรียกใช้โค้ดจากระยะไกล (RCE) บนไซต์โดยใช้ปลั๊กอินที่อนุญาตให้เรียกใช้ PHP จากภายในโพสต์และหน้า หนึ่งแคมเปญดังกล่าวพยายามที่จะฉีด PHP รวมถึงการเพิ่มเนื้อหาจากไซต์ที่ถูกบุกรุกแล้วฉีดแบ็คดอร์ที่ซ่อนอยู่ใน /wp-content/uploads

“การทำลายล้างไม่ได้ให้ผลตอบแทนทางเศรษฐกิจ ดังนั้นมันอาจจะตายในไม่ช้า” Cid กล่าว “สิ่งที่จะยังคงอยู่คือความพยายามที่จะรันคำสั่ง (RCE) เนื่องจากทำให้ผู้โจมตีสามารถควบคุมไซต์ได้อย่างสมบูรณ์ – และเสนอวิธีการสร้างรายได้หลายวิธี – และ SPAM SEO / ลิงค์พันธมิตร / การฉีดโฆษณา เราเริ่มเห็นว่ามีความพยายามในไซต์สองสามแห่ง และนั่นน่าจะเป็นทิศทางที่ช่องโหว่นี้จะถูกนำไปใช้ในทางที่ผิดในอีกไม่กี่วัน สัปดาห์ และอาจเป็นเดือนข้างหน้า”

แฮกเกอร์กำลังกำหนดเป้าหมายไปยังไซต์ใดๆ ที่ยังไม่ได้อัปเดตเป็น 4.7.2 ดูเหมือนว่าจะไม่มีรูปแบบใดในนั้นเลย การดูผลลัพธ์ของ Google อย่างรวดเร็วสำหรับแคมเปญที่มีความเคลื่อนไหวมากที่สุดแสดงให้เห็นว่าไซต์ที่ถูกบุกรุก ได้แก่ บล็อก สื่อ รัฐบาล การศึกษา กีฬา การแพทย์ และเทคโนโลยี

เหตุใด REST API จึงถูกเปิดใช้งานโดยค่าเริ่มต้น

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

“ปัญหาด้านความปลอดภัยอยู่ในคุณสมบัติที่ฉันไม่ได้ใช้ในเว็บไซต์ใด ๆ ของฉัน (REST API) แต่ถึงกระนั้น คุณลักษณะนี้จะถูกเปิดใช้งานโดยค่าเริ่มต้นเป็นอันดับแรก และครั้งที่สอง เนื่องจาก WordPress 4.7 คุณจำเป็นต้องมีปลั๊กอิน – ซึ่งอาจทำให้เกิดปัญหาด้านความปลอดภัยเพิ่มเติม – เพื่อปิดการใช้งานคุณสมบัติ?” ผู้ใช้รายหนึ่ง (@helios2121) แสดงความคิดเห็นในโพสต์ “โปรดคิดใหม่วิธีการรักษาความปลอดภัยของคุณ สร้างคุณลักษณะที่ทุกคนไม่จำเป็นต้องเลือกใช้ หรือ อย่างน้อยก็ ให้วิธีการเลือกไม่ใช้โดยไม่ต้องใช้ปลั๊กอินเพิ่มเติม”

Morten Rand-Hendriksen เปิดตั๋ว trac เพื่อหารือเกี่ยวกับการปิดใช้งาน REST API โดยค่าเริ่มต้นและเปิดใช้งานเฉพาะเมื่อผู้ดูแลไซต์ร้องขอเท่านั้น หรือธีมหรือปลั๊กอินขึ้นอยู่กับมัน

Core Committer Sergey Biryukov ยืนยันว่าแผนจะแนะนำฟังก์ชันหลักเพิ่มเติมที่อาศัย REST API "การปิด REST API ก็เหมือนการปิด admin-ajax.php ซึ่งทั้งสองอย่างจะทำให้ไซต์ของคุณเสียหาย" Biryukov กล่าว

Rand-Hendriksen ถามว่าทำไมจุดสิ้นสุดของเนื้อหาจึงไม่ได้รับการปกป้องโดยค่าเริ่มต้น ในขณะที่อนุญาตให้เปิด REST API ตามค่าเริ่มต้นสำหรับวัตถุประสงค์ของผู้ดูแลระบบ ผู้ใช้รายอื่นถามว่าทำไมจุดปลายผู้ใช้ไม่ได้รับการปกป้องโดยค่าเริ่มต้น (เช่น https://news.microsoft.com/wp-json/wp/v2/users หรือ https://www.oba.org/wp-json/wp /v2/users) ซึ่ง "ทำให้การรับชื่อผู้ใช้ทั้งหมดง่ายกว่าที่เคย" บนไซต์ใดๆ ที่ใช้ 4.7+

“หากคุณต้องการปิดการใช้งาน REST API บนไซต์ของคุณจริง ๆ นี่คือคำแนะนำปัจจุบันของเรา: จำกัดเฉพาะผู้ใช้ที่ตรวจสอบสิทธิ์” James Nylen กล่าว “อย่างไรก็ตาม เราต้องการเพิ่มการยอมรับและการใช้งาน REST API ต่อไป และฉันคาดหวังว่าการปรับเปลี่ยนนี้จะทำลายฟังก์ชันการทำงานของ WP มากขึ้นเรื่อยๆ เมื่อเวลาผ่านไป เช่น ธีมที่ขับเคลื่อนด้วย API และการฝัง”

Nylen แนะนำปลั๊กอิน Disable JSON API สำหรับผู้ที่ต้องการปฏิบัติตามคำแนะนำนั้นบนไซต์ที่ใช้ WordPress 4.7+ ปัจจุบันปลั๊กอินมีการติดตั้งที่ใช้งานอยู่มากกว่า 10,000 ครั้ง

ทีมรักษาความปลอดภัยของ WordPress ทำงานอย่างขยันขันแข็งเพื่อบรรเทาการโจมตีโดยช่วยโฮสต์และบริษัทรักษาความปลอดภัยวางการป้องกันไว้ก่อนที่ปัญหาจะเผยแพร่สู่สาธารณะ อย่างไรก็ตาม การเปิดเผยช่องโหว่ทั้งหมดถูกฝังอยู่ในบล็อก Make/Core ซึ่งเป็นเว็บไซต์ที่เจ้าของเว็บไซต์ WordPress ทั่วไปไม่ได้อ่านกันอย่างกว้างขวาง ลิงก์ไปยังการเปิดเผยดังกล่าวได้รับการเผยแพร่เป็นส่วนเสริมของโพสต์ก่อนหน้าในบล็อกข่าว WordPress ในสัปดาห์ต่อมา

“ในขณะที่ฉันซาบซึ้งในการเปิดเผยปัญหานี้อย่างรับผิดชอบและพยายามแก้ไขปัญหานี้ ฉันหวังว่าคุณจะพิจารณาทำการประกาศในอนาคตผ่านการโพสต์ใหม่บนไซต์ WordPress News แทนที่จะเพิ่มการอัปเดตในโพสต์ก่อนหน้า” ผู้ใช้ @johnrork แสดงความคิดเห็น ในการเปิดเผยอย่างเป็นทางการ “ฉันอาจไม่ใช่คนเดียวที่สามารถหลีกเลี่ยงการถูกประนีประนอมได้หากสิ่งนี้ปรากฏเป็นรายการใหม่ในโปรแกรมอ่าน RSS ของฉันในวันพุธ”

บรรดาผู้ที่อ่านบล็อกของ Make สามารถเริ่มต้นแก้ไขไซต์ของตนเองและ/หรือไซต์ของลูกค้าได้ ผู้ที่พึ่งพาบล็อกข่าว WordPress สำหรับข้อมูลเกี่ยวกับการอัปเดตด้านความปลอดภัยอาจอ่านโพสต์เมื่อเผยแพร่ครั้งแรกและไม่เคยกลับมาดูการอัปเดตในสัปดาห์ต่อมา ปัญหาร้ายแรงนี้รับประกันความโปร่งใสของ WordPress ในโพสต์ใหม่ในบล็อกข่าว สิ่งนี้จะส่งทวีตโดยอัตโนมัติไปยังผู้ติดตามมากกว่าครึ่งล้านในบัญชี WordPress อย่างเป็นทางการและบัญชี Facebook ที่มีมากกว่าล้านไลค์

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