“Browser Sync” ความสะดวกสบายที่กลายเป็นช่องทางลับสำหรับแฮ็กเกอร์

Key Message

ฟีเจอร์ Browser Sync อาจเป็นช่องโหว่ที่สร้างช่องทางลับให้แฮ็กเกอร์สามารถ Bypass ระบบรักษาความปลอดภัยขององค์กร (เช่น Firewall และ VPN) ได้ เมื่อพนักงานใช้บัญชีงาน และบัญชีส่วนตัวบน Browser เดียวกัน
หากคอมพิวเตอร์ส่วนตัวที่บ้านติดมัลแวร์ หรือมีการติดตั้ง Extension อันตราย สิ่งเหล่านั้นจะถูก Sync เข้าสู่คอมพิวเตอร์ที่ทำงานโดยอัตโนมัติ ซึ่งอาจนำไปสู่การเข้าถึงข้อมูลสำคัญ และระบบภายในขององค์กร
ช่องโหว่นี้อาจนำไปสู่การขโมยข้อมูล (Data Exfiltration), การขโมยรหัสผ่าน และ Session Cookies (ซึ่งอาจใช้ Bypass MFA ได้) รวมถึงการเจาะเข้าสู่ระบบภายในขององค์กร
องค์กรควรปิดการใช้งาน Browser Sync ในระดับนโยบาย (ใช้ GPO/MDM) และจำกัดการติดตั้ง Extension ให้เหลือเฉพาะที่ได้รับอนุมัติจากฝ่าย IT เท่านั้น

       ในยุคที่การทำงานแบบ Hybrid Work กลายเป็นเรื่องปกติ ฟีเจอร์ "Browser Sync" ทำให้พนักงานสามารถล็อกอิน Google Chrome ที่บ้าน และเข้าถึงข้อมูล Bookmark, รหัสผ่าน และประวัติการท่องเว็บทั้งหมดจากที่ทำงานได้ทันที ซึ่งเป็นความสะดวกสบายที่ทุกคนต้องการ

       แต่ในมุมมองด้านความปลอดภัยไซเบอร์ ความสะดวกสบายนี้อาจกลายเป็นจุดอ่อนร้ายแรงที่เปิดทางให้แฮ็กเกอร์เข้าสู่ระบบขององค์กรได้โดยง่าย
Browser Sync : ดาบสองคมที่เชื่อม "เรื่องส่วนตัว" เข้ากับ "เรื่องงาน"
       โดยปกติแล้ว องค์กรส่วนใหญ่มักลงทุนอย่างมหาศาลไปกับ Firewall, VPN, และ Antivirus เพื่อป้องกันเครือข่ายภายในให้ปลอดภัยที่สุด

       แต่ฟีเจอร์ Browser Sync กลับเปรียบเสมือนช่องทางลับที่แฮ็กเกอร์สามารถใช้เพื่อ Bypass การป้องกันเหล่านั้นไปได้ทั้งหมด
ทำไมจึงเป็นเช่นนั้น?
       เราลองมาดูความเป็นไปได้ที่ฟีเจอร์ Browser Sync จะถูกใช้เพื่อโจมตีองค์กรได้อย่างไร

1. การใช้งานหลายบัญชีพร้อมกัน: พนักงานล็อกอินบัญชี Gmail ทั้งขององค์กร และส่วนตัวบนเว็บ Browser เดียวกัน และสร้าง Profile สำหรับบัญชีเหล่านั้นไว้บนเว็บ Browser

2. การเปิดใช้งานฟีเจอร์ Browser Sync: พนักงานเปิดฟีเจอร์ "Turn on sync" บนเว็บ Browser ที่ใช้บนคอมพิวเตอร์ที่ทำงาน (ซึ่งมี Profile ทั้งบัญชีขององค์กร และบัญชีส่วนตัวอยู่)

3. การเชื่อมต่อจากที่บ้าน: เมื่อกลับถึงบ้าน คอมพิวเตอร์ส่วนตัวของพนักงานมีการล็อกอินบัญชีส่วนตัวอยู่แล้ว และมีการสร้าง Profile ของบัญชีส่วนตัวบน Browser ด้วยเช่นเดียวกัน (บางคนอาจมีการล็อกอินบัญชีองค์กรที่บ้านด้วย)

ภัยคุกคามจากมัลแวร์: หากคอมพิวเตอร์ที่บ้านติดมัลแวร์ หรือแฮ็กเกอร์ขโมย Session Token ของบัญชี Google ไปได้ แฮ็กเกอร์จะสามารถเข้าถึง Browser Profile ของพนักงานคนนั้นได้ทันที
ข้อมูลถูกเข้าถึง: ข้อมูลสำคัญทั้งหมด เช่น Bookmark, รหัสผ่าน และประวัติการท่องเว็บ ที่อยู่บนคอมพิวเตอร์ที่ทำงาน จะถูกเข้าถึงได้จากคอมพิวเตอร์ที่บ้านโดยอัตโนมัติผ่านฟีเจอร์ Browser Sync

4. ภัยคุกคามจาก Extension อันตราย: คอมพิวเตอร์ที่บ้านมักมีความปลอดภัยน้อยกว่า (ทั้งในด้าน Endpoint Protection และระบบ Network) พนักงานอาจถูกหลอกให้ติดตั้ง Extension ที่เป็นอันตรายบน Browser โดยไม่รู้ตัว

Extension ถูก Sync อัตโนมัติ: เมื่อเปิดฟีเจอร์ Browser Sync อยู่ Extension อันตรายที่ติดตั้งบนคอมพิวเตอร์ที่บ้านก็จะถูก Sync มาอยู่บนคอมพิวเตอร์ที่ทำงานโดยอัตโนมัติ โดยไม่ผ่านการตรวจสอบของอุปกรณ์ความปลอดภัยขององค์กรเลย

ผลกระทบที่อาจเกิดขึ้น

การขโมยข้อมูล (Data Exfiltration): Extension อันตรายอาจสามารถอ่านข้อมูลทุกอย่างบนหน้าเว็บที่พนักงานเปิด รวมถึงข้อมูลที่เป็นความลับของบริษัท, อีเมลภายใน หรือระบบภายในต่าง ๆ เช่น CRM/ERP
การขโมยรหัสผ่าน และ Session: หากพนักงาน Save Password ไว้ใน Browser แฮ็กเกอร์ที่เข้าถึงบัญชีหลักได้ ก็สามารถดึงรหัสผ่านเหล่านั้นไปใช้ได้ทันที รวมถึงอาจสามารถขโมย Session Cookies เพื่อใช้ในการ Bypass การป้องกันจาก MFA (Multi Factor Authentication) ได้ในบางกรณี
การเจาะเข้าสู่ระบบภายใน (Internal Access): Browser บนเครื่องบริษัทมักจะมีสิทธิ์เข้าถึง Intranet หรือ Server ภายใน ทำให้ Extension ที่เป็นอันตรายสามารถทำหน้าที่เป็น Proxy ให้แฮ็กเกอร์อาจสามารถส่งคำสั่งเข้ามาโจมตีระบบภายในองค์กรได้โดยตรง

แนวทางการป้องกัน

ปิดการใช้งาน Browser Sync ในระดับนโยบาย: ผู้ดูแลระบบสามารถใช้ Group Policy (GPO) หรือ MDM เพื่อบังคับปิดฟีเจอร์ Sync ใน Browser ระดับองค์กร ไม่ให้พนักงานใช้บัญชีส่วนตัวมาล็อกอิน หรือแยก Profile งานกับส่วนตัวให้ชัดเจน
จำกัดการติดตั้ง Extension: อนุญาตให้ติดตั้งเฉพาะ Browser Extensions ที่ผ่านการตรวจสอบ และอนุมัติโดยฝ่าย IT เท่านั้น ห้ามไม่ให้พนักงานติดตั้ง Extension เองโดยอิสระ
สร้างความตระหนักรู้ (User Awareness Training): สร้างความตระหนักรู้ให้พนักงานเข้าใจว่าเครื่องส่วนตัวห้ามนำมาใช้ทำงาน และการล็อกอินบัญชีองค์กรในเครื่องที่บ้านที่ใช้ร่วมกับคนอื่น มีความเสี่ยงสูงมาก

บทสรุป
       โดยสรุปแล้ว ช่องโหว่นี้ไม่ได้เกิดจาก Bug ของซอฟต์แวร์ แต่เกิดจาก Logic ของความเชื่อใจ เมื่อองค์กรให้ความเชื่อใจกับพนักงานมากเกินไปว่ามีความความตระหนักรู้ หรือมีความปลอดภัยแล้ว รวมถึงอาจวางใจจากการที่มีการป้องกันด้วย MFA หรืออุปกรณ์ด้านความปลอดภัยอื่น ๆ จนลืมตรวจสอบบริบทของการใช้งานอุปกรณ์ของพนักงาน 

       ฟีเจอร์ Browser Sync ถูกออกแบบมาเพื่อความสะดวก โดยอนุมานว่า "ถ้าผู้ใช้ล็อกอินได้ ก็แสดงว่าเชื่อถือได้" แต่ในความเป็นจริง ผู้ใช้อาจล็อกอินจากอุปกรณ์ที่ถูก Compromised ไปแล้ว การอนุญาตให้ Sync ข้ามอุปกรณ์ (จากบ้านที่ไม่มี Security ไปยังออฟฟิศที่มี High Security) จึงเป็นการ Bypass ระบบความปลอดภัยขององค์กรได้อย่างสิ้นเชิง

       Browser Sync อาจช่วยให้พนักงานทำงานง่ายขึ้น แต่สำหรับองค์กร มันคือจุดอ่อนร้ายแรงที่อาจส่งมัลแวร์จากคอมพิวเตอร์ที่บ้านตรงเข้าสู่ระบบสำคัญขององค์กร

       ในฐานะผู้ดูแลระบบ ควรต้องเร่งตรวจสอบ Policy ของ Browser ของพนักงาน ว่าองค์กรกำลังเปิดช่องทางลับนี้ทิ้งไว้หรือไม่ ก่อนที่แฮ็กเกอร์จะใช้ช่องทางนี้นำมาใช้ในการโจมตีองค์กร

Defense in Depth: ยกระดับการป้องกันด้วย WAF และ EDR สู่มาตรฐานใหม่ในการป้องกันระบบ

Key Message

แฮ็กเกอร์มีความสามารถสูงขึ้นมากในปัจจุบัน การป้องกันระบบด้วยอุปกรณ์ใดอุปกรณ์หนึ่ง อาจไม่เพียงพออีกต่อไป การทำงานร่วมกันด้วย Defense in Depth Concept อาจเป็นมาตรการป้องกันที่มีประสิทธิภาพมากขึ้น
แฮ็กเกอร์ที่มีความสามารถระดับสูงมีเทคนิคมากมายในการหลบเลี่ยงการตรวจจับจาก WAF ผ่านการปรับเปลี่ยน Payload ซึ่งอาจทำให้ Signature เดิม ๆ ตรวจจับไม่ได้
ในการป้องกัน WAF (รวมถึง IPS/NGFW) จำเป็นอย่างยิ่งที่จะต้องเห็น Payload ของการโจมตีทั้งหมดเพื่อจับ Exploit ได้อย่างแม่นยำ ซึ่งหากไม่ได้มีการกำหนดค่า Decrypt SSL อย่างถูกต้อง ระบบอาจจะไม่สามารถตรวจจับการโจมตีได้

       เมื่อช่วงต้นเดือนธันวาคม 2025 ได้มีการค้นพบช่องโหว่การเรียกใช้โค้ดที่เป็นอันตรายจากระยะไกล (RCE) โดยไม่ต้องผ่านการยืนยันตัวตน ระดับ Critical ในโปรโตคอล "Flight" ของ React Server Components (RSC) ซึ่งช่องโหว่นี้ส่งผลกระทบต่อ React 19 Ecosystem และเฟรมเวิร์กที่ใช้งาน โดยเฉพาะอย่างยิ่ง Next.

“Zero-Click” Again!! “CVE-2025-48593” ช่องโหว่ใหม่ที่ (อาจ) เป็นฝันร้ายของผู้ใช้ Android

Key Message

มีรายงานช่องโหว่ RCE ระดับ Critical CVE-2025-48593 ในรูปแบบ Zero-Click บนระบบปฏิบัติการ Android
ผู้โจมตีสามารถรันโค้ดอันตรายจากระยะไกลบนอุปกรณ์เหยื่อได้ทันที เพียงแค่อุปกรณ์ยังไม่ได้ทำการอัปเดต โดยที่เหยื่อไม่ต้องดำเนินการใด ๆ ทั้งสิ้น ไม่ต้องคลิก, ไม่ต้องเปิดไฟล์
ส่งผลกระทบต่อ Android (AOSP) เวอร์ชัน 13, 14, 15, และ 16
วิธีแก้ไขช่องโหว่ที่ดีที่สุดคือการอัปเดตแพตช์ November 2025 Android Security Bulletin ที่ Google ได้ปล่อยออกมาแล้วทันที
สำหรับผู้ที่ยังไม่สามารถอัปเดตได้ ควรพิจารณา ปิด Bluetooth ชั่วคราว โดยเฉพาะในพื้นที่ที่มีผู้คนหนาแน่น เพื่อลดความเสี่ยงจากการถูกโจมตี

เมื่อวันที่ 3 พฤศจิกายน 2025 ที่ผ่านมา Google ได้เผยแพร่ Android Security Bulletin ประจำเดือนพฤศจิกายน ซึ่งมีการเปิดเผยช่องโหว่ด้านความปลอดภัยหลายรายการ และหนึ่งในนั้นที่สร้างความกังวลให้กับผู้ใช้งาน Android เป็นอย่างมาก คือช่องโหว่ CVE-2025-48593 ซึ่งถูกระบุว่าเป็นช่องโหว่ระดับ Critical และเป็นช่องโหว่ประเภท Zero-Click Remote Code Execution (RCE)

โดยช่องโหว่แบบ “Zero-Click” เป็นช่องโหว่ที่ทำให้ผู้โจมตีสามารถรันโค้ดที่เป็นอันตรายบนอุปกรณ์ของเหยื่อได้โดยที่เหยื่อไม่จำเป็นต้องดำเนินการใด ๆ ทั้งสิ้น ไม่ต้องคลิก, ไม่ต้องเปิดไฟล์ ก็อาจถูกโจมตีได้ทันที ลักษณะการโจมตีที่ง่ายดายเช่นนี้ ทำให้ช่องโหว่ CVE-2025-48593 ถูกคาดหมายว่าอาจเป็น "ฝันร้าย" สำหรับผู้ใช้งาน Android
รายละเอียดทางเทคนิคของ CVE-2025-48593

หมายเลข CVE (CVE ID) : CVE-2025-48593
ระดับความรุนแรง (Severity) : Critical (ตามการประเมินของ Google ใน Android Security Bulletin)
ประเภทของช่องโหว่ (Vulnerability Type) : Remote Code Execution (RCE)
ระบบที่ได้รับผลกระทบ (Affected Component) : System Component ของ Android
การโต้ตอบจากผู้ใช้ (User Interaction) : “Zero-Click” ไม่ต้องอาศัยการโต้ตอบใด ๆ จากผู้ใช้งาน
ผู้รายงานช่องโหว่ (Researcher) : Dikun Zhang จาก Li Auto security team
เวอร์ชันที่ได้รับผลกระทบ (Affected Versions) : Android (AOSP) 13, 14, 15, 16
วิธีการลดผลกระทบ (Mitigation) :  อัปเดตแพตซ์ November 2025 Android Security Bulletin

ข้อมูลเพิ่มเติมของช่องโหว่
ช่องโหว่นี้ถูกเปิดเผยอย่างเป็นทางการโดย Google ใน Security Bulletin ของ Android ประจำเดือนพฤศจิกายน 2025 โดย Google ให้เครดิตการค้นพบ และรายงานช่องโหว่กับ Dikun Zhang (Stardesty) นักวิจัยจากทีมความปลอดภัยของ Li Auto

โดยการที่นักวิจัยสังกัดบริษัทรถยนต์เป็นผู้ค้นพบช่องโหว่ แสดงให้เห็นถึงความก้าวหน้าของเทคโนโลยียานยนต์ในปัจจุบัน เนื่องจากระบบบันเทิงในรถยนต์สมัยใหม่ถูกสร้างขึ้นบน Android Open Source Project (AOSP) มากขึ้น การค้นพบช่องโหว่นี้แสดงให้เห็นว่า ในขณะที่พื้นที่การโจมตีของ Android ขยายไปสู่โครงสร้างพื้นฐานที่สำคัญ นักวิจัยจากอุตสาหกรรมที่ได้รับผลกระทบใหม่ ๆ เหล่านี้กำลังกลายเป็นส่วนสำคัญในการค้นพบช่องโหว่ในโค้ดหลักของ AOSP

ถึงแม้ยังไม่มีรายละเอียดของช่องโหว่ และวิธีการโจมตีจาก Google ออกมาอย่างเป็นทางการ แต่จากการวิเคราะห์ทางเทคนิคที่ปรากฏในรายงานของ Tenable และการอ้างอิงโค้ดจาก AOSP (Android Open Source Project) พบว่าช่องโหว่นี้มีสาเหตุมาจาก Android Component ซึ่งเกี่ยวข้องกับโมดูล Bluetooth โดยเฉพาะอย่างยิ่งในส่วนของ Hands-Free Client (HF Client) โดย Tenable ระบุว่า ช่องโหว่นี้เป็นช่องโหว่ในลักษณะ Use-After-Free ซึ่งเกิดขึ้นในฟังก์ชัน bta_hf_client_cb_init ภายในไฟล์ bta_hf_client_main.

เราจะเชื่อ AI ได้อย่างไร… เมื่อ ‘คำตอบที่มั่นใจ’ อาจมาจากข้อมูลที่ไม่ถูกต้อง

Key Message

AI ทำงานบนพื้นฐานของการคาดเดาความน่าจะเป็นของคำตอบที่น่าจะเป็นไปได้มากที่สุด แต่ไม่ได้ทำความเข้าใจด้วยตรรกะเช่นเดียวกับมนุษย์
AI อาจเกิดอาการ Hallucinate เพราะถูกสอนให้ตอบอย่างมั่นใจ แทนที่จะตอบว่าไม่รู้
ปัจจุบันบริษัทระดับโลกยังต้องใช้งบประมาณในการลงทุนอย่างมหาศาลเพื่อการพัฒนาความสามารถของ AI อย่างต่อเนื่อง
หากให้ AI ช่วยเขียนโค้ด มันจะสร้างโค้ดจากสิ่งที่น่าจะเป็นไปได้มากที่สุดตามที่ได้รับการฝึกฝนมา แต่ไม่ใช่โค้ดที่ถูกต้อง หรือปลอดภัยที่สุด
คุณภาพของข้อมูลที่ใช้ฝึกฝน AI ในปัจจุบันยังไม่สูงพอ ยิ่งโดยเฉพาะในมุม Cybersecurity ที่มีการเปลี่ยนแปลงอย่างรวดเร็วของภัยคุกคาม และช่องโหว่
เมื่อองค์กรต่าง ๆ เชื่อ AI มากเกินไป เราอาจมี "Lost Generation of Engineers" ซึ่งขาด Engineers ที่รู้วิธีแก้ปัญหาช่องโหว่ หรือเขียนโค้ดที่ปลอดภัยอย่างแท้จริงตั้งแต่เริ่มต้นไป
AI เป็นเทคโนโลยีที่มีประโยชน์ แต่ในปัจจุบัน ผู้ใช้งาน และองค์กรต่าง ๆ ควรตระหนักถึงความเสี่ยงจากความถูกต้องของข้อมูล และไม่ควรเชื่อถือ AI มากเกินไปโดยไม่มีการตรวจสอบข้อมูลซ้ำอีกครั้ง

 

ในยุคปัจจุบัน AI ถูกพูดถึงมากขึ้นอย่างแพร่หลาย ทั้งจากการรายงานข่าวทางโทรทัศน์, ทาง Social Media หรือแม้แต่จากผู้คนทั่ว ๆ ไป ที่ก็นำ AI มาใช้งานในชีวิตประจำวันในรูปแบบต่าง ๆ และทำให้กลายเป็นมาตรฐานในวงการ Tech ที่บริษัทระดับโลกต่างก็ต้องมีการนำ AI มาใช้ ไม่ทางใดก็ทางหนึ่ง หรือบางรายก็เป็นเจ้าของ AI ซะเอง จึงเป็นสาเหตุให้ผลิตภัณฑ์ทางด้าน Technology ในปัจจุบัน ต้องโฆษณาว่ามีการนำ Technology AI มาใช้ใน Product หรือบริการ หรือนำมาใช้ทดแทน ’มนุษย์’ ในการทำงานได้ เพราะหากไม่เป็นเช่นนั้น อาจไม่ถูกพิจารณา หรือถูกมองว่าล้าสมัยไปเลยด้วยซ้ำ

แต่เทคโนโลยีนี้ต้องใช้งบประมาณลงทุนมหาศาล ยกตัวอย่างเช่น

Meta ยอมลงทุนกว่า $100M เพื่อดึงตัวผู้เชี่ยวชาญทางด้าน AI จากบริษัทอื่น ๆ
OpenAI ที่ก็ลงทุนไปก่อนหน้านี้จำนวนมากกับ ChatGPT
Google ก็ลงทุนไปกับการพัฒนา Gemini ไปอย่างน้อยมากกว่า $192M

ซึ่งแสดงให้เห็นว่าบริษัทเหล่านี้ยังคงมองว่า Technology AI ในปัจจุบัน ยังจำเป็นต้องได้รับการพัฒนาอย่างต่อเนื่อง จึงเกิดคำถามว่า เราจะเชื่อมั่นได้อย่างไรว่า Technology AI อื่น ๆ ที่อ้างว่าสามารถนำมาใช้ทดแทนการทำงานของ ‘มนุษย์’ ได้ แต่อาจพัฒนาด้วยงบประมาณที่จำกัด จะสามารถทำงานได้อย่างถูกต้อง และมีประสิทธิภาพจริง

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

มีคลิปวิดีโอหนึ่งบน Youtube ของช่อง “Logically Answered” ที่พูดถึงความผิดพลาดของ AI โดยยกตัวอย่างจาก Vibe Coding (การพัฒนาซอฟต์แวร์โดยใช้ AI เพื่อสร้างโค้ด) ได้อย่างน่าสนใจ

Youtube : https://www.

รับมือภัยคุกคามจากช่องโหว่ RCE บน SharePoint (CVE-2025-53770) ได้อย่างทันท่วงทีด้วย EDR จาก CrowdStrike

เมื่อวันหรือสองวันก่อนนี้ ทั่วโลกต่างพูดถึงภัยคุกคามร้ายแรงจากช่องโหว่ Zero-day : SharePoint  Remote Code Execution (CVE-2025-53770) ซึ่งเป็นช่องโหว่ที่ทำให้ผู้ไม่หวังดีสามารถเข้าควบคุมเซิร์ฟเวอร์ SharePoint ได้จากระยะไกล ผ่าน Internet หรือผ่านระบบเครือข่ายและดูเหมือนว่าจะเริ่มถูกนำไปใช้โจมตีเป็นวงกว้างแล้ว (Exploited in the Wild)

Reference: https://msrc.

Through the Tunnel : ป้องกันความเสี่ยงจากการใช้งาน AWS SSM Port Forwarding

บทนำ
AWS SSM Session Manager เป็นเครื่องมือที่ทำให้สามารถ Remote เข้าไปยัง EC2 Instances ได้โดยไม่ต้องเปิดการเข้าถึงจาก Internet ซึ่งถือเป็น Best Practice ที่ทาง Amazon Web Services (AWS) แนะนำ แทนการใช้ Secure Shell (SSH) เนื่องมาจากความเสี่ยงในการเปิด Port SSH ให้เข้าถึงได้จาก Internet

SSM Session Manager มีหลายฟีเจอร์ โดยหนึ่งใน​ Feature คือ Port Forwarding ที่ช่วยสร้างช่องทางการเชื่อมต่อผ่าน SSM Service ระหว่างผู้ใช้งานกับ EC2 Instances ได้อย่างปลอดภัยโดยไม่ต้องมีการเปิด Port ใด ๆ

อย่างไรก็ตามฟีเจอร์นี้ ถ้ามีการตั้งค่าผิดพลาด หรือใช้งานอย่างไม่เหมาะสม อาจทำให้เกิดความเสี่ยงทางด้านความปลอดภัย เช่น การใช้ข่องทางนี้เพื่อเชื่อมต่อไปยังเครื่องอื่น ๆ ภายใน AWS Cloud ที่ติดตั้ง SSM Agent

บทความนี้จะนำเสนอถึงความเสี่ยงที่อาจเกิดขี้นจาการใช้งานฟีเจอร์ Port Forwarding และวิธีการป้องกันเพื่อเพิ่มความปลอดภัยให้กับระบบ
ความเสี่ยงที่อาจจะเกิดขึ้น ?
เมื่อ AWS SSM Port Forwarding ถูกตั้งค่าอย่างไม่เหมาะสม อาจนำไปสู่สถานการณ์ต่อไปนี้:

การเข้าถึง EC2 Instances โดยไม่ได้รับอนุญาต : ผู้โจมตีอาจสามารถใช้ SSM Port Forwarding เพื่อเข้าถึง EC2 Instances ที่ไม่ได้รับการป้องกัน ซึ่งอาจนำไปสู่การเปลี่ยนแปลง หรือการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต
การขโมยข้อมูล : ผู้โจมตีอาจสามารถสร้าง Secure Tunnel เพื่อขโมยข้อมูลที่มีความสำคัญออกจาก EC2 Instances โดยไม่ถูกตรวจจับ เช่น การใช้ SCP เพื่อถ่ายโอนข้อมูลที่มีความสำคัญ
การโจมตีต่อไปภายในระบบ (Lateral Movement) : ผู้โจมตีอาจใช้ SSM Port Forwarding เพื่อเชื่อมต่อไปยัง Internal Server หรือระบบอื่น ๆ ในเครือข่าย เพื่อขยายผลการโจมตี และเข้าถึงข้อมูลที่มีความสำคัญเพิ่มเติม

เหตุการณ์เหล่านี้แสดงให้เห็นถึงความเสี่ยงที่อาจเกิดขึ้น หากไม่มีการตั้งค่า และใช้งาน SSM Port Forwarding อย่างเหมาะสม

AWS SSM Manager คืออะไร ?
AWS Systems Manager Session Manager เป็นบริการ Managed Service จาก AWS ที่ช่วยให้สามารถจัดการ EC2 Instances ได้อย่างปลอดภัย โดยไม่จำเป็นต้องใช้การเข้าถึงผ่าน SSH หรือ Bastion Host โดยผู้ดูแลระบบสามารถสร้างการเข้าถึงแบบ Shell หรือ Command Line ไปยัง EC2 Instances ผ่านทาง AWS Management Console, AWS CLI หรือ SDKs โดยไม่ต้องเปิด Instances ให้เข้าถึงได้จาก Internet

 
AWS SSM Port Forwarding คืออะไร ?
AWS SSM Port Forwarding เป็นฟีเจอร์ที่ทำงานคล้ายกับ SSH Tunneling แต่แทนที่จะใช้ SSH เป็นการใช้ SSM Agent ในสร้างการเขื่อมต่อ (Tunnel) ระหว่างเครื่องผู้ใช้งาน (Local Machine) และ EC2 Instance ที่อยู่บน Cloud

โดยผู้ใช้งานต้องมีสิทธิ์ต่อไปนี้ :

สิทธิ์ IAM User ที่เหมาะสม
การติดตั้ง AWS CLI กับ Session Manager Plugin บนเครื่อง Local Machine

 
ประโยชน์ของ SSM Port Forwarding :

ไม่จำเป็นต้องใช้ Public IP หรือเปิด Port : ช่วยลดความเสี่ยงจากการโจมตีผ่าน Internet
ไม่ต้องกำหนด Inbound Security Group (Firewall Policy) : เพิ่มความปลอดภัยให้กับระบบโดยรวม
ใช้ Debug Application ที่อยู่ใน Private Subnet : สามารถเชื่อมต่อเพื่อแก้ไขปัญหาได้โดยไม่ต้องเปิด Endpoint ให้เข้าถึงได้จาก Internet
ใช้จัดการ Database : เช่น การเชื่อต่อไปยัง Database ที่ไม่มี Public Endpoint

รายละเอียดเชิงเทคนิคเกี่ยวกับความผิดพลาดที่อาจเกิดขึ้น :
1. การเข้าถึง EC2 Instances โดยไม่ได้รับอนุญาต
หนึ่งในความผิดพลาดที่พบบ่อยของ Developer หรือ Administrator คือการเขียน IAM Policy ที่มี Resource: ""* ซึ่งไม่ได้จำกัดการเข้าถึงอย่างรัดกุม ทำให้ผู้ใช้งานสามารถเข้าถึง และสร้างการเชื่อมต่อ (Tunnel) ไปยัง EC2 Instances ได้ทุกเครื่องใน AWS Account ซึ่งอาจนำไปสู่ปัญหาด้านความปลอดภัย เช่น การเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต หรือการโจมตีต่อไปยังภายในระบบแบบ Lateral Movement

ตัวอย่าง IAM Policy ที่ไม่ปลอดภัย

การตั้งค่าลักษณะนี้ทำให้ผู้ใช้งานสามารถเริ่ม Session Manager กับ EC2 Instances ได้โดยไม่มีการควบคุมว่าเป็น Instance ใด ซึ่งเป็นช่องโหว่ที่สำคัญในด้านการตั้งค่าความปลอดภัย

 
2. การขโมยข้อมูล (Data Exfiltration)
ผู้โจมตีอาจสามารถใช้คำสั่ง ssm start-session เพื่อสร้างการเชื่อมต่อ (Tunnel) ไปยัง Port 22 บน EC2 Instance ซึ่งเป็นพอร์ตที่ใช้สำหรับ SSH โดยเฉพาะ โดยการเชื่อมต่อนี้จะช่วยให้ผู้โจมตีสามารถเข้าถึง และ Copy ไฟล์ข้อมูลสำคัญออกจากเครื่องได้อย่างง่ายดาย

ตัวอย่างคำสั่ง :

สร้างการเชื่อมต่อ (Tunnel) ผ่าน SSM : คำสั่งนี้เป็นการสร้างการเชื่อมต่อจาก Port 22 บน EC2 Instance ไปยัง Port 1022 บนเครื่อง Local

$ aws aws ssm start-session \

--target instance-id \

--document-name AWS-StartPortForwardingSession \

--parameters '{"portNumber":["22"], "localPortNumber":["1022"]}'
 

Copy ไฟล์ผ่าน SCP : คำสั่งนี้ใช้ SCP เพื่อคัดลอกไฟล์ secret-data.

การยกระดับการป้องกันและตรวจจับการโจมตีประเภท Web Shell ด้วยระบบ Endpoint Detection and Response (EDR)

หลังจากที่ได้รู้จักกับ Web Shell ว่าคืออะไร กันแล้วนั้นใน What is Web Shell?

แล้วรู้หรือไม่ว่าเราสามารถป้องกัน Web Server ของเราจากการโจมตีของ Web Shell ให้ดีขึ้นได้ด้วยระบบ Endpoint Detection and Response (EDR)

เพราะเบื้องหลังการโจมตีเหล่านั้นคือ กระบวนการที่ผู้โจมตีได้ป้อนชุดคำสั่ง (Input System Command) ผ่าน Web Browser ซึ่งจะทำให้ Web Server Process (เช่น IIS, PHP, JAVA, Node.

Critical vulnerabilities in libwebp (WebP) library

A recently identified vulnerability within the web application library (libwebp) has the potential to lead to RCE (Remote Code Execution) when exploited and can allow hackers to run malicious code in your system. This vulnerability is specifically a heap-based buffer overflow issue found within the libwebp library, which serves the purpose of decoding and encoding WebP image files.

What is Webshell?

ช่วงหลัง ๆ เราจะได้ยินคำว่า Webshell กันค่อนข้างบ่อยครั้ง วันนี้ i-secure จะพาเพื่อนๆ มารู้จักว่า Webshell ซึ่งเป็นหนึ่งในเทคนิคการโจมตีที่พบได้บ่อยมากๆ ในปัจจุบัน

Webshell คืออะไร และทำไมมันจึงเป็นวิธีการที่เหล่า Hacker นิยมใช้ในการโจมตีเหยื่อกันบ่อยครั้ง

ก่อนอื่น ต้องทำความเข้าใจวิธีคิดที่ Hacker คิดก่อน จุดมุ่งหมายหลักของ Hacker คือต้องการเข้าถึงข้อมูลของเหยื่อ เช่น เข้าถึงข้อมูลความลับ (Confidentiality) หรือเข้าไปดัดแปลงแก้ไขข้อมูลให้เปลี่ยนแปลงไป (Integrity) หรือไม่ก็ทำการขัดขวางไม่ให้ใครๆเข้าถึงข้อมูลนั้นๆได้ (Availability)

ดังนั้นการที่จะบรรลุวัตถุประสงค์นั้นได้ ก็คือต้องควบคุมเหยื่อให้ได้ จึงเป็นที่มาของ Webshell ที่จะเข้าไปคอยควบคุมเครื่องคอมพิวเตอร์หรือเซิร์ฟเวอร์ของเป้าหมายนั่นเอง 

แล้ว Webshell คืออะไร?

Webshell คือไฟล์ที่ Hacker สร้างขึ้นมาเพื่อใช้สำหรับควมคุมเครื่อง Web Server ของเหยื่อหลังจาก Hacker พบช่องทางในการโจมตี โดย Webshell ถูกเขียนด้วยภาษาของ Web Application ยกตัวอย่างเช่นภาษา PHP เป็นต้น โดยใช้ประโยชน์จากคำสั่งหรือ Library ที่สามารถเรียกใช้งานของระบบ System Command หรือ OS Command คำสั่งเช่น “whoami” ,”ipconfig /all”, “mkdir” เป็นต้น 

แผนผังการทำงานของ Webshell ที่รอรับ input จาก Attacker
Ref: https://www.