นักวิจัยจาก Lightspin พบช่องโหว่ AWS IAM Authenticator for Kubernetes (CVE-2022-2385) ซึ่งสามารถทำให้ผู้โจมตีสามารถแก้ไข authentication token เพื่อยกระดับสิทธิ์ใน Kubernetes cluster ได้

AWS IAM Authenticator for Kubernetes คืออะไร?

AWS IAM Authenticator เป็น plugin ที่ช่วย map user/group ใน Kubernetes กับ AWS IAM ทำให้ผู้ใช้งานที่ใช้ AWS อยู่แล้วไม่ต้องบริหารจัดการสิทธ์ที่ Kubernetes โดยการเพิ่มหรือลดสิทธิ์ของ user ก็สามารถทำที่ AWS IAM ได้เลย โดยที่ AWS IAM Authenticator จะถูกติดตั้งอยู่ใน AWS EKS cluster ตั้งแต่เริ่มต้น

AWS IAM Authenticator ทำงานอย่างไร?

เมื่อ user จะยืนตัวตน kubectl จะส่ง token ที่เป็นการ request API GetCallerIdentity ไปที่ AWS IAM Authenticator server จากนั้น Server จะส่ง token ไปให้ AWS STS อีกครั้งเพื่อเป็นการยืนตัวตน AWS IAM กับ User/Group ใน Cluster

สาเหตุของช่องโหว่

Authenticator server จะดึงค่าจาก API GetCallerIdentity parameter มา verify และนำมาใช้ในการยื่นยันตัวตน แต่มี code บางส่วนที่จะทำหน้าที่ lower case ตัว key ของ parameter แต่กลับไม่มีการตรวจสอบว่าชื่อ key นั้นซ้ำกันหรือไม่ เช่น key ‘Action’ กับ ‘action’ เมื่อถูกแปลงเป็น lowercase แล้วจะมีชื่อเดียวกันเป็น ‘action’ ซึ่งทำให้อาจมีโอกาสที่จะถูก Overwrite ค่าของ parameter ได้

วิธีการโจมตี

aws-iam-authenticator สามารถ map user โดยใช้ AWS AccessKeyID

ผู้โจมตีสามารถแก้ไข Access Key ที่ใช้โดย aws-iam-authenticator โดยการส่ง request overwrite parameter ‘X-Amz-Credentials’

https[:]//sts[.]us-east-1[.]amazonaws[.]com/?X-Amz-Credentials=AKIAXXXXXXXXXXXXXXXX&x-amz-credentials=AKIABBBBBBBBBBBBBBBB

authenticator server จะเอา AccessKeyID มาจาก query parameter ที่โดน overwrite แล้วนำมาเขียนลง AccessKeyID template value  ซึ่งอาจนำไปสู่การยกระดับสิทธิ์ในคลัสเตอร์ EKS เกิดขึ้นได้

วิธีการแก้ไข :

AWS อัปเดตแพตซ์เพื่อแก้ไขช่องโหว่ดังกล่าวเรียบร้อยแล้ว ซึ่งผู้ใช้งานไม่ต้องดำเนินการใดๆ
Self host Kubernetes clusters อัปเดต aws-iam-authenticator เป็น v0.5.9
ไม่ควรใช้ AccessKeyID template value ในการ map user/group

ที่มา : blog.

Unit42 จาก Palo Alto Networks ประกาศการค้นพบแคมเปญการโจมตีใหม่จากกลุ่มแฮกเกอร์ TeanTNT ซึ่งพุ่งเป้าโจมตีสภาพแวดล้อมระบบที่มีการใช้งาน Kubernetes ด้วยมัลแวร์ Hildegard โดยมีจุดประสงค์หลักในการทำ Cryptojacking

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

ลักษณะสำคัญของมัลแวร์ Hidlegard คือมีการติดตั้งกับเซิร์ฟเวอร์ที่ใช้ออกคำสั่งและควบคุมผ่านโปรโตคอล IRC, มีฟังก์ชันในการซ่อนกระบวนการทำงานและโปรเซสในลักษณะที่คล้ายมัลแวร์ในกลุ่ม Rootkit และยังไม่สามารถถูกใช้เพื่อขโมยข้อมูลที่มีอยู่ออกไปด้วย

เราขอแนะนำให้ผู้ใช้งาน ผู้พัฒนาและผู้ดูแลระบบตรวจสอบการตั้งค่าของสภาพแวดล้อมว่ามีการตั้งค่าอย่างปลอดภัย รวมไปถึงเฝ้าระวังเพื่อระบุหาการทำงานที่ผิดปกติที่อาจเกิดขึ้นในระดับ container ด้วย

ที่มา: securityweek.

ทีมนักวิจัย Unit 42 จาก Palo Alto Networks ได้เผยถึงการพบเวิร์ม cryptojacking ที่มีชื่อว่า “Black-T” จากกลุ่ม TeamTNT ซึ่งเป็นกลุ่มที่รู้จักกันในการกำหนดเป้าหมายเพื่อโจมตี AWS จากนั้นทำการใช้ Monero (XMR) cryptocurrency โดยเวิร์มที่ถูกค้นพบนั้นได้ถูกพัฒนาใหม่ทั้งการเพิ่มความสามารถในการขโมยรหัสผ่านและเครื่องสแกนเครือข่ายเพื่อให้ง่ายต่อการแพร่กระจายไปยังอุปกรณ์ที่มีช่องโหว่อื่นๆ

จากรายงานของทีมนักวิจัย Unit 42 พบว่า TeamTNT ได้เพิ่มความสามารถของมัลแวร์ในการใช้เครื่องมือ zgrab ซึ่งเป็นเครื่องมือสแกนเครือข่ายชนิดเดียวกับ pnscan และ masscan ที่อยู่ภายใน Black-T อยู่แล้วทำการสแกนเป้าหมาย ทั้งนี้เครื่องมือสแกน masscan ที่ใช้โดย Black-T ก็ได้รับการอัปเดตเพื่อกำหนดเป้าหมายเป็นพอร์ต TCP 5555 ซึ่งอาจบอกเป็นนัยว่า TeamTnT อาจกำหนดเป้าหมายไปที่อุปกรณ์ Android นอกจากนี้ Black-T ยังได้เพิ่ม Mimikatz แบบโอเพนซอร์สสองตัวคือ mimipy (รองรับ Windows / Linux / macOS) และ mimipenguin (รองรับ Linux) ทำการอ่านข้อมูลรหัสแบบ plaintext ภายในหน่วยความจำของระบบที่ถูกบุกรุกและส่งไปยังเซิร์ฟเวอร์ C&C ของ TeamTNT

ด้วยการรวมเทคนิคและขั้นตอนทั้งหมดเข้าด้วยกัน TeamTNT สามารถใช้บ็อตเน็ตของเซิร์ฟเวอร์ที่ถูกบุกรุกเพื่อทำการสแกนหา Docker daemon API เพิ่มเติม ภายในเครือข่ายโดยใช้เครื่องมือ masscan, pnscan และ zgrab และเมื่อมัลแวร์สามารถบุกรุกแล้วได้จะทำการติดตั้ง Kubernetes และ Docker และหลังจากนั้นจะปรับใช้ payload binary ใน container เพื่อทำการเริ่มต้น Monero (XMR) cryptocurrency ภายในเครื่องที่บุกรุก

ทั้งนี้ผู้ดูแลระบบควรทำการตรวจสอบให้แน่ใจว่า Docker daemon API บนระบบคลาวด์ของท่านไม่ถูกเปิดเผยและสามารถเข้าถึงได้จากอินเตอร์เน็ตและเพื่อเป็นการป้องกันการตกเป็นเหยือของมัลแวร์ ผู้ดูแลระบบควรใช้ทำการติดตั้งและใช้งาน Next-Generation Firewall ในระบบของท่าน

ที่มา : bleepingcomputer

Kubernetes ออกแพตช์แก้ช่องโหว่ DoS

Kubernetes ออกแพตช์แก้สองช่องโหว่ร้ายแรงที่มีผลกระทบต่อทุกเวอร์ชัน ช่องโหว่ดังกล่าวยอมให้ผู้โจมตีทำให้ระบบหยุดทำงาน (DoS)

Kubernetes เป็น open-source สำหรับการจัดการ Container ที่เริ่มต้นพัฒนามาจาก Google ด้วยภาษา Go มันถูกออกแบบมาเพื่อให้การ deploy การปรับขนาด และการจัดการ Container เป็นไปอย่างอัตโนมัติ

ปัญหาด้านความปลอดภัยได้ถูกพบในไลบรารี่ net/http ของภาษา Go ที่กระทบต่อทุกเวอร์ชันและทุก component ของ Kubernetes ช่องโหว่นี้สามารถทำให้เกิด DoS ในกระบวนที่เกี่ยวของกับ HTTP หรือ HTTPS listener ซึ่งช่องโหว่นี้เกี่ยวข้องกับช่องโหว่ที่ Netflix พบช่องโหว่ที่เกี่ยวข้องกับ HTTP/2 เมื่อวันที่ 13 สิงหาคมที่ผ่านมา

จากทั้งหมด 8 ช่องโหว่ที่ Netflix พบ มีเพียงสองช่องโหว่ที่กระทบ Kubernetes คือ CVE-2019-9512 และ CVE-2019-9514

CVE-2019-9512 หรือที่เรียกว่า Ping Flood
แฮกเกอร์สามารถทำการ Ping อย่างต่อเนื่องจนระบบล่ม

CVE-2019-9514 หรือที่เรียกว่า Reset Flood
แฮกเกอร์ขอ streams จำนวนมากและส่งคำขอไม่ถูกต้องทำให้เกิด RST_STREAM จำนวนมาก ส่งผลทำให้ CPU ถูกใช้งานมากเกินไปทำให้ระบบล่มได้

Kubernetes ได้ปล่อยแพตช์ใหม่ที่แก้ไขช่องโหว่นี้และแนะนำให้อัพเดทให้เร็วที่สุดเท่าที่จะทำได้

ด้านล่างนี้เป็น Kubernetes รุ่นใหม่ที่สร้างมาจากภาษา Go รุ่นที่แก้ปัญหาแล้ว

* Kubernetes รุ่น1.15.3 สร้างมาจากภาษา Go 1.12.9
* Kubernetes v1.14.6 สร้างมาจากภาษา go1.12.9
* Kubernetes v1.13.10 สร้างมาจากภาษา go1.11.13

ผู้ดูแลระบบ Kubernetes สามารถอัปเกรดได้ทุกแพลตฟอร์มบนเพจ Kubernetes Cluster Management

ที่มา: bleepingcomputer

แจ้งเตือนช่องโหว่ใน runc กระทบ LXC, Docker และ Kubernetes รันโค้ดอันตรายทะลุถึงโฮสต์ได้

นักพัฒนาประจำโครงการ runc ซึ่งเป็น container runtime ให้กับโครงการ container หลายโครงการได้ออกมาประกาศการค้นพบช่องโหว่รหัส CVE-2019-5736 วันนี้ การโจมตีช่องโหว่นี้จะส่งผลให้ผู้โจมตีสามารถรันโค้ดอันตรายด้วยสิทธิ์ระดับสูงในระบบโฮสต์ได้ ช่องโหว่นี้ได้คะแนน CVSSv3 7.2 คะแนน

ช่องโหว่ดังกล่าวจะถูกโจมตีได้เมื่อมีการรัน container ที่ถูกสร้างขึ้นมาอย่างเฉพาะ โดย container ดังกล่าวนั้นจะเขียนทับไบนารีของ runc บนโฮสต์เพื่อรันโค้ดที่เป็นอันตรายด้วยสิทธิ์ root ได้

ช่องโหว่นี้จะไม่ถูกบล็อคโดยการตั้งค่าเริ่มต้นของ AppArmor และ SELinux บน Fedora หากมีการติดตั้ง moby-engine แต่จะถูกบล็อคหากการใช้งาน namepsace นั้นมีลักษณะที่รัดกุมพอ เช่น ไม่มีการ map โฮสต์เข้ากับ namspace ของ container

runc ถูกใช้เป็น container runtime ในหลายโครงการ อาทิ Docker, cri-o, containerd, Kubernetes และ Apache Mesos ซึ่งยืนยันแล้วว่าได้รับผลกระทบจากช่องโหว่

ผู้ใช้งานที่ได้รับผลกระทบควรดำเนินการอัปเดตซอฟต์แวร์ใดๆ ที่มีการใช้งาน runc เป็นเวอร์ชันล่าสุดที่มีการแพตช์แล้วโดยด่วน

ที่มา : bleepingcomputer

พบช่องโหว่ความปลอดภัยที่สำคัญของ Kubernetes

Kubernetes กลายเป็นระบบคอนเทนเนอร์บนคลาวด์ที่เป็นที่นิยมมากที่สุด ล่าสุดมีการค้นพบช่องโหว่ความปลอดภัยที่สำคัญ Kubernetes Privilege Escalation (CVE-2018-1002105) มีความความรุนแรงเป็น Critical (CVSS 9.8/10)

ช่องโหว่นี้ส่งผลให้ผู้ใช้งานที่ส่ง request ซึ่งได้รับการดัดแปลง เพื่อทำการเชื่อมต่อผ่านทาง API ของ Kubernetes ไปยัง backend server ได้ เมื่อการเชื่อมต่อสำเร็จแล้ว ผู้ใช้งานจะสามารถส่ง request ใดๆ ก็ตามไปยัง backend server ได้โดยตรง

ในการกำหนดค่าเริ่มต้นผู้ใช้ทั้งหมด ไม่ว่าเป็นแบบ authenticated หรือ unauthenticated จะได้รับอนุญาตให้ดำเนินการเรียกใช้งาน API ที่มีช่องโหว่ดังกล่าวนี้ ดังนั้นไม่ว่าผู้ใช้งานจะเป็นใครก็ตามก็สามารถทำการโจมตีได้ และจากรายงานระบุว่ายังไม่มีวิธีการที่สามารถใช้ตรวจจับการโจมตีผ่านช่องโหว่ดังกล่าวได้อย่างง่ายดาย

อย่างไรก็ตามยังมีข่าวดีในข่าวร้ายสำหรับผู้ใช้งานบางคน ข่าวดีคือมีการแก้ไขช่องโหว่ดังกล่าวออกมาแล้ว แต่ข่าวร้ายคือผู้ใช้งานต้องทำการอัปเกรดเวอร์ชั่นของ Kubernetes ซึ่งอาจไม่เป็นที่ชอบใจของผู้ใช้งานบางราย โดยผู้ใช้งานเวอร์ชั่น v1.0.x ถึง1.9.x จะต้องหยุดใช้งานและทำการอัปเดทเป็นเวอร์ชั่น v1.10.11, v1.11.5, v1.12.3 และ v1.13.0-rc.