หน่วยงานความมั่นคงทางไซเบอร์ และความปลอดภัยของโครงสร้างพื้นฐานของสหรัฐอเมริกา (CISA) ได้เพิ่มช่องโหว่ Oracle WebLogic Server และ Mitel MiCollab ลงในแค็ตตาล็อก Known Exploited Vulnerabilities (KEV)

CVE-2020-2883 (คะแนน CVSS 9.8) เป็นช่องโหว่ใน Oracle WebLogic Server (เวอร์ชัน 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0) โดยผู้โจมตีที่ไม่ผ่านการยืนยันตัวตนที่สามารถเข้าถึงเครือข่ายผ่าน IIOP หรือ T3 สามารถใช้ประโยชน์จากช่องโหว่นี้เพื่อโจมตี Oracle WebLogic Server ได้

รายงานที่เผยแพร่โดย ZDI ระบุว่า “ช่องโหว่นี้ทำให้ผู้โจมตีสามารถเรียกใช้โค้ดที่เป็นอันตรายจากระยะไกลบน Oracle WebLogic ที่มีช่องโหว่ โดยไม่ต้องผ่านการยืนยันตัวตน โดยช่องโหว่นี้เกิดขึ้นในกระบวนการจัดการ T3 protocol โดยข้อมูลที่ถูกสร้างขึ้นใน T3 protocol message สามารถ trigger การ deserialization ข้อมูลที่ไม่น่าเชื่อถือได้ ทำให้ผู้โจมตีสามารถใช้ช่องโหว่นี้ในการรันโค้ดตามที่ต้องการด้วยสิทธิ์ของ Process ปัจจุบัน”

CVE-2024-41713 (คะแนน CVSS 9.8) เป็นช่องโหว่ Path Traversal ใน Mitel MiCollab (จนถึงเวอร์ชัน 9.8 SP1 FP2) โดยเป็นช่องโหว่ NuPoint Unified Messaging ที่ทำให้เกิดการโจมตีแบบ path traversal ได้โดยไม่ต้องผ่านการยืนยันตัวตน ซึ่งอาจเสี่ยงต่อความถูกต้องของข้อมูล และการกำหนดค่า

“ช่องโหว่ Path Traversal CVE-2024-41713 ใน NuPoint Unified Messaging (NPM) component ของ Mitel MiCollab อาจทำให้ผู้โจมตีที่ไม่ผ่านการยืนยันตัวตนสามารถทำการโจมตีแบบ path traversal ได้ เนื่องจากการตรวจสอบอินพุตที่ไม่เหมาะสม หากสามารถโจมตีช่องโหว่นี้ได้สำเร็จอาจทำให้ผู้โจมตีสามารถเข้าถึงระบบได้ ซึ่งอาจส่งผลต่อความถูกต้องสมบูรณ์ของข้อมูล รวมถึงความพร้อมใช้งานของระบบ ซึ่งช่องโหว่นี้สามารถถูกโจมตีได้โดยไม่ต้องผ่านการยืนยันตัวตน”

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

CVE-2024-55550 (คะแนน CVSS 9.8) เป็นช่องโหว่ Path Traversal ใน Mitel MiCollab (จนถึงเวอร์ชัน 9.8 SP2) ช่องโหว่นี้ทำให้ผู้โจมตีที่ผ่านการยืนยันตัวตน และมีสิทธิ์ระดับผู้ดูแลระบบสามารถอ่านไฟล์ภายในระบบได้ อย่างไรก็ตามการโจมตีโดยใช้ช่องโหว่นี้จำกัดเฉพาะข้อมูลที่ไม่มีความสำคัญเท่านั้น

“ช่องโหว่ Path Traversal, CVE-2024-55550, ใน Mitel MiCollab อาจทำให้ผู้โจมตีที่ผ่านการยืนยันตัวตน และมีสิทธิ์ระดับผู้ดูแลระบบสามารถอ่านไฟล์ในระบบได้ เนื่องจากการตรวจสอบข้อมูลอินพุตที่ไม่เพียงพอ”

ตามคำสั่งปฏิบัติการ (BOD) 22-01: การลดความเสี่ยงของช่องโหว่ที่กำลังถูกใช้ในการโจมตีอยู่ในปัจจุบัน หน่วยงาน FCEB จำเป็นต้องแก้ไขช่องโหว่ที่ระบุภายในระยะเวลาที่กำหนด เพื่อปกป้องเครือข่ายจากการโจมตีโดยใช้ช่องโหว่เหล่านี้

CISA ยังแนะนำให้องค์กรภาคเอกชนตรวจสอบช่องโหว่ที่อยู่ในแคตตาล็อก และแก้ไขช่องโหว่ในระบบของพวกเขาเช่นเดียวกัน

โดย CISA ได้สั่งให้หน่วยงานรัฐบาลกลางแก้ไขช่องโหว่นี้ภายในวันที่ 28 มกราคม 2025

ที่มา : securityaffairs.

พบกลุ่ม Hacker กำลังใช้กลวิธีเพื่อหลอกล่อให้ผู้ใช้งานปิดฟีเจอร์ Phishing Protection สำหรับข้อความของ Apple iMessage และหลังจากนั้นก็เปิดกลับมาอีกครั้ง

(more…)

มีรายละเอียดใหม่เกี่ยวกับแคมเปญฟิชชิงที่กำหนดเป้าหมายไปยังผู้พัฒนา extension ของเบราว์เซอร์ Chrome ซึ่งนำไปสู่การถูกเจาะข้อมูลของ extension อย่างน้อย 35 รายการ เพื่อแทรกโค้ดที่ใช้สำหรับขโมยข้อมูลไว้ ซึ่งรวมถึง extension จากบริษัทด้านความปลอดภัยทางไซเบอร์อย่าง Cyberhaven ด้วย (more…)

Ivanti แจ้งเตือนการพบ Hacker กำลังมุ่งเป้าการโจมตีโดยใช้ช่องโหว่การเรียกใช้คำสั่งที่เป็นอันตรายจากระยะไกล (RCE) ของ Connect Secure หมายเลข CVE-2025-0282 ซึ่งเป็นช่องโหว่ Zero-Day ที่ถูกใช้เพื่อติดตั้งติดตั้งมัลแวร์บนอุปกรณ์

Ivanti พบช่องโหว่ดังกล่าว หลังจากที่ Ivanti Integrity Checker Tool (ICT) ตรวจพบพฤติกรรมที่เป็นอันตรายบนอุปกรณ์ของลูกค้า Ivanti จึงได้เริ่มการสอบสวน และยืนยันว่าพบ Hacker ใช้ช่องโหว่ CVE-2025-0282 โจมตีเป้าหมายในรูปแบบ Zero-Day

CVE-2025-0282 (คะแนน CVSS 9.0/10 ความรุนแรงระดับ Critical) เป็นช่องโหว่ Stack-Based Buffer Overflow ใน Ivanti Connect Secure ก่อนเวอร์ชัน 22.7R2.5, Ivanti Policy Secure ก่อนเวอร์ชัน 22.7R1.2 และ Ivanti Neurons สำหรับเกตเวย์ ZTA ก่อนเวอร์ชัน 22.7R2.3 ซึ่งทำให้ Hacker ที่ไม่ผ่านการยืนยันตัวตนสามารถเรียกใช้คำสั่งที่เป็นอันตรายจากระยะไกลได้

แม้ว่าช่องโหว่ดังกล่าวจะส่งผลกระทบต่อผลิตภัณฑ์ทั้ง 3 รายการ แต่ Ivanti เปิดเผยว่าพบเห็นการโจมตีในอุปกรณ์ Ivanti Connect Secure เท่านั้น โดย Ivanti ได้ออกอัปเดตเพื่อแก้ไขช่องโหว่ในเฟิร์มแวร์เวอร์ชัน 22.7R2.5 ในส่วนของอัปเดตเพื่อแก้ไขช่องโหว่สำหรับ Ivanti Policy Secure และ Ivanti Neurons สำหรับ ZTA Gateway จะถูกปล่อยในวันที่ 21 มกราคม 2025 ซึ่งจะพร้อมใช้งานใน Standard Download Portal

Ivanti Policy Secure เนื่องจากโซลูชันนี้ไม่ได้ถูกออกแบบให้เชื่อมต่อกับอินเทอร์เน็ต ซึ่งทำให้ความเสี่ยงในการถูกโจมตีช่องโหว่นี้ลดลงอย่างมาก ทั้งนี้ลูกค้าควรตรวจสอบให้แน่ใจเสมอว่าอุปกรณ์ IPS ของตนได้รับการกำหนดค่าตามคำแนะนำของ Ivanti และไม่เปิดให้เข้าถึงได้จากอินเทอร์เน็ต เนื่องจาก Ivanti Policy Secure อาจถูกโจมตีจากช่องโหว่ดังกล่าวได้

Ivanti Neurons for ZTA Gateways ไม่สามารถถูกโจมตีได้ เมื่ออยู่ในการใช้งานบน production แต่หากมีการสร้าง gateway สำหรับโซลูชันนี้ และไม่ได้เชื่อมต่อกับ ZTA controller ก็มีความเสี่ยงที่ gateway ที่ถูกสร้างขึ้นจะถูกโจมตีจากช่องโหว่ได้

Ivanti แนะนำให้ผู้ดูแลระบบ Ivanti Connect Secure ดำเนินการทำ ICT scan ทั้งภายใน และภายนอก หากสแกนพบสัญญาณของการโจมตี Ivanti แนะนำให้ผู้ดูแลระบบทำการ factory reset ก่อนอัปเดตเป็น Ivanti Connect Secure 22.7R2.5 แต่ถึงแม้หากผลการสแกนออกมาไม่พบสัญญาณของการโจมตี Ivanti ก็ยังคงแนะนำให้ผู้ดูแลระบบทำการ factory reset ก่อนอัปเดตเป็น Ivanti Connect Secure 22.7R2.5 เช่นเดียวกัน

ทั้งนี้ Ivanti ยังได้ออกอัปเดตช่องโหว่อีกรายการ คือ CVE-2025-0283 ซึ่งเป็นช่องโหว่ที่ทำให้ Hacker สามารถยกระดับสิทธิ์ได้ ซึ่งช่องโหว่นี้ไม่ได้เกี่ยวข้องกับช่องโหว่ CVE-2025-0282 และปัจจุบันยังไม่พบการโจมตีจากช่องโหว่ดังกล่าว

โดย Ivanti กำลังทำงานร่วมกับ Mandiant และ Microsoft Threat Intelligence Center เพื่อสืบสวนการโจมตี ซึ่งอาจจะมีรายงานที่เกี่ยวกับมัลแวร์ที่ตรวจพบเร็ว ๆ นี้

ในเดือนตุลาคม 2023 Ivanti ได้ออกอัปเดตด้านความปลอดภัยเพื่อแก้ไขการโจมตีช่องโหว่ Zero-Day บน Cloud Services Appliance (CSA) จำนวน 3 รายการที่กำลังถูกใช้ในการโจมตีอย่างต่อเนื่อง

ที่มา : bleepingcomputer

พบแคมเปญ Phishing ที่มุ่งเป้าหมายการโจมตีไปยังบริษัทผู้ผลิตยานยนต์ เคมีภัณฑ์ และอุตสาหกรรมในเยอรมนี และสหราชอาณาจักร โดยใช้ HubSpot เพื่อขโมย credentials ของบัญชี Microsoft Azure

โดยกลุ่ม Hacker ได้ใช้ลิงก์ HubSpot Free Form Builder และ PDF ที่เลียนแบบ DocuSign เพื่อเปลี่ยนเส้นทางของเหยื่อไปยังเว็บไซต์ Phishing เพื่อขโมยข้อมูล credentials

ตามรายงานของทีมนักวิจัย Unit 42 ของ Palo Alto Networks พบแคมเปญ Phishing ดังกล่าวมาตั้งแต่เดือนมิถุนายน 2024 และยังคงดำเนินการอยู่จนถึงเดือนกันยายน 2024 ซึ่งขโมย Azure account ไปแล้วประมาณ 20,000 บัญชี

ใช้ HubSpot เพื่อรวบรวมข้อมูล Credentials
**

HubSpot เป็นแพลตฟอร์มการจัดการลูกค้าสัมพันธ์ (CRM) ซึ่งถูกใช้ในระบบการตลาดอัตโนมัติ, การขาย, การบริการลูกค้า, การวิเคราะห์ และการสร้างเว็บไซต์ และ landing pages
**

Form Builder เป็นฟีเจอร์ที่ช่วยให้ผู้ใช้สามารถสร้างแบบฟอร์มออนไลน์ที่กำหนดเองเพื่อรวบรวมข้อมูลจากผู้เยี่ยมชมเว็บไซต์

นักวิจัย Unit 42 พบว่า Hacker ได้ใช้ HubSpot Form Builder เพื่อสร้างแบบฟอร์มหลอกลวงอย่างน้อย 17 แบบ เพื่อล่อลวงเหยื่อให้กรอกข้อมูล credentials ที่มีความสำคัญในโดเมน '.buzz' ซึ่งเลียนแบบหน้าเข้าสู่ระบบของ Microsoft Outlook Web App และ Azure

รวมถึง Hacker ยังใช้เว็บไซต์ที่เลียนแบบระบบการจัดการเอกสารของ DocuSign สำนักงานรับรองเอกสารของฝรั่งเศส และพอร์ทัลการเข้าสู่ระบบเฉพาะองค์กรในการโจมตีด้วย

โดยต่อมาเหยื่อจะถูกส่งต่อไปยังหน้าเว็บไซต์เหล่านั้นโดย phishing messages ที่มีโลโก้ DocuSign ซึ่งมี links ไปยัง HubSpot โดยเป็น PDF ที่แนบมา หรือ HTML ที่ฝังไว้ในเมล์

เนื่องจากอีเมลทั่วไปมองว่าการแนบ links ไปยัง HubSpot ไม่เป็นอันตราย จึงทำให้ email security tools จะไม่ระบุว่า links เหล่านั้น มีแนวโน้มที่จะเป็น Phishing Email ทำให้จะสามารถเข้าถึงกล่องจดหมายของเป้าหมายได้มากกว่า เนื่องจากไม่ผ่านการตรวจสอบจาก Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) และ Domain-based Message Authentication, Reporting, และ Conformance (DMARC)

สิ่งที่เกิดขึ้นหลังการโจมตีสำเร็จ

นักวิจัย Unit 42 พบว่าหลังจากโจมตีด้วย Phishing Campaign สำเร็จ Hacker จะใช้ VPN เพื่อทำให้ดูเหมือนว่าตั้งอยู่ในประเทศขององค์กรที่ตกเป็นเหยื่อ และหากฝ่ายไอทีพยายามกลับมาควบคุมบัญชีดังกล่าว Hacker ก็จะเริ่มต้นการรีเซ็ตรหัสผ่านทันทีเพื่อพยายามที่จะเข้าควบคุมบัญชีอีกครั้ง

โดยทั้งนี้แม้ว่าเซิร์ฟเวอร์ส่วนใหญ่ที่ทำหน้าที่เป็น backbone ของแคมเปญ Phishing จะออฟไลน์ไปนานแล้ว แต่การดำเนินการดังกล่าวก็ยังนับว่าเป็นตัวอย่างของการโจมตีของแคมเปญที่พบ เนื่องจาก Hacker พยายามจะค้นหาช่องทางใหม่ ๆ เพื่อหลีกเลี่ยงเครื่องมือด้านความปลอดภัยอยู่เสมอ

ที่มา : bleepingcomputer

 

 

 

 

Apache Software Foundation (ASF) ออกแพตซ์อัปเดตด้านความปลอดภัยเพื่อแก้ไขช่องโหว่ระดับ Critical ในซอฟต์แวร์ Tomcat Server ที่อาจทำให้เกิดการเรียกใช้โค้ดที่เป็นอันตรายจากระยะไกล (RCE) ภายใต้เงื่อนไขบางอย่าง

ช่องโหว่ดังกล่าวมีหมายเลข CVE-2024-56337 ถูกระบุว่าเป็นการแก้ไขปัญหาที่ไม่สมบูรณ์ของช่องโหว่ CVE-2024-50379 (คะแนน CVSS: 9.8) ซึ่งเป็นช่องโหว่ด้านความปลอดภัยระดับ Critical อีกช่องโหว่หนึ่งในผลิตภัณฑ์เดียวกัน และเคยได้รับการแก้ไขไปแล้วเมื่อวันที่ 17 ธันวาคม 2024

นักพัฒนาได้ระบุในคำแนะนำเมื่อสัปดาห์ที่แล้วว่า "ผู้ใช้ที่ใช้งาน Tomcat บนระบบไฟล์ที่ไม่คำนึงถึงตัวพิมพ์เล็ก-ใหญ่ (case insensitive) และเปิดใช้งานการเขียน default servlet (ตั้งค่าพารามิเตอร์ readonly เริ่มต้นเป็นค่า false ซึ่งไม่ใช่ค่าเริ่มต้น) อาจจำเป็นต้องตั้งค่าเพิ่มเติม เพื่อแก้ไขช่องโหว่ CVE-2024-50379 ให้สมบูรณ์ แต่ก็ขึ้นอยู่กับเวอร์ชั่นของ Java ที่ใช้งานร่วมกับ Tomcat ด้วย"

ช่องโหว่ทั้งสองรายการเป็นช่องโหว่แบบ Time-of-check Time-of-use (TOCTOU) ที่อาจส่งผลให้เกิดการเรียกใช้โค้ดบนระบบไฟล์ที่ไม่แยกความแตกต่างระหว่างตัวอักษรพิมพ์เล็ก-พิมพ์ใหญ่ เมื่อมีการเปิดใช้งาน default servlet สำหรับการเขียน

Apache ระบุไว้ในการแจ้งเตือนสำหรับ CVE-2024-50379 "การอ่าน และการอัปโหลดพร้อมกันภายใต้โหลดของไฟล์เดียวกัน สามารถหลีกเลี่ยงการตรวจสอบความแตกต่างของตัวอักษรพิมพ์เล็ก-พิมพ์ใหญ่ของ Tomcat และทำให้ไฟล์ที่อัปโหลดถูกมองว่าเป็น JSP ซึ่งจะนำไปสู่การเรียกใช้โค้ดที่เป็นอันตรายจากระยะไกลได้"

CVE-2024-56337 ส่งผลกระทบต่อ Apache Tomcat ตามเวอร์ชันต่อไปนี้

Apache Tomcat 11.0.0-M1 ถึง 11.0.1 (แก้ไขแล้วในเวอร์ชั่น 11.0.2 หรือเวอร์ชันใหม่กว่า)
Apache Tomcat 10.1.0-M1 ถึง 10.1.33 (แก้ไขแล้วในเวอร์ชั่น 10.1.34 หรือเวอร์ชันใหม่กว่า)
Apache Tomcat 9.0.0.M1 ถึง 9.0.97 (แก้ไขแล้วในเวอร์ชั่น 9.0.98 หรือเวอร์ชันใหม่กว่า)

นอกจากนี้ ผู้ใช้งานจำเป็นต้องดำเนินการเปลี่ยนแปลงการตั้งค่าต่อไปนี้ ขึ้นอยู่กับเวอร์ชันของ Java ที่กำลังใช้งาน

Java 8 หรือ Java 11: กำหนดค่า system property sun.

ศูนย์วิทยาศาสตร์สุขภาพมหาวิทยาลัย Texas Tech และหน่วยงานในเมือง El Paso ถูกโจมตีทางไซเบอร์ ส่งผลให้ระบบคอมพิวเตอร์ และแอปพลิเคชันเกิดความเสียหาย และอาจทำให้ข้อมูลของผู้ป่วย 1.4 ล้านรายถูกเปิดเผย

(more…)

บทนำ
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.