SCARLETEEL ถูกพบโดย Sysdig บริษัทด้านความปลอดภัยทางไซเบอร์ในขณะที่ทำการวิเคราะห์เหตุการณ์การโจมตีทางไซเบอร์บนระบบคลาวด์ให้กับลูกค้ารายหนึ่ง

สำหรับปฏิบัติการดังกล่าวของ 'SCARLETEEL' จะกำหนดเป้าหมายไปที่เว็บแอปพลิเคชันที่ทำงานภายใต้ containers เพื่อทำให้การโจมตีสามารถเข้าถึงบริการ cloud services และขโมยข้อมูลที่มีความสำคัญออกไปได้ (more…)

Introduction
โดยปกติแล้วภายหลังจากที่ผู้โจมตีสามารถเข้าควบคุม AWS account ของเหยื่อได้แล้ว มักจะพบการใช้เทคนิคในการพยายามแฝงตัวอยู่ในระบบ (persistence) บน AWS เช่น การสร้าง IAM User และ Create access key หรือการสร้าง/แก้ไข Role trust policy ให้สามารถ Assume Role จาก account ของผู้โจมตีได้ แต่วิธีการเหล่านี้ถือว่าค่อนข้างง่ายต่อการถูกตรวจจับ

ในวันที่ 06 เมษายน 2022 AWS ประกาศ Lambda ฟีเจอร์ใหม่ที่ชื่อว่า Lambda function URLs [1] ซึ่งทำให้ Lambda function สามารถมี API Endpoint ได้โดยไม่ต้องใช้ API Gateway (more…)

สรุปรายละเอียดของช่องโหว่

ช่องโหว่เกิดขึ้นบน undocumented API ที่เกี่ยวข้องกับการเขียน Image
ช่องโหว่ทำให้สามารถแก้ไข้ Public ECR images ของ AWS account ใดก็ได้
ช่องโหว่ทำให้สามารถใช้โจมตี Image ที่เป็นนิยมเช่น Nginx, Amazon Linux, Ubuntu เพื่อใช้โจมตีแบบ Supply chain attack ได้

Amazon ECR Public Gallery เป็น public container repositories ให้บริษัทต่าง ๆ สามารถนำ Container Image มา Host เพื่อให้บริการกับลูกค้าเช่น NGINX, Ubuntu, Amazon Linux และ HashiCorp

นักวิจัยจาก Lightspin ค้นหา Internal API action ใน Amazon ECR Public Gallery JavaScript File พบว่ามี Action Name บางตัวที่ไม่ได้ถูก Document ไว้ และเป็น Action ที่เกียวข้องกับการเขียน Image 4 ตัวดังนี้

- DeleteImageForConvergentReplicationInternal
- DeleteTagForConvergentReplicationInternal
- PutImageForConvergentReplicationInternal
- PutLayerForConvergentReplicationInternal

แต่ว่า Internal API จำเป็นต้องมี identity credentials นักวิจัยจึงทำการ Intercept ECR Public Gallery request พบว่า ECR Public Gallery ใช้ credentials ที่ได้มาจาก API ของ Amazon Cognito

Amazon Cognito เป็น service ทีช่วยเรื่องการ authentication เพื่อให้ user สามารถเข้าใช้ resources บน AWS ได้ โดยที่ API ในการ Get Credentials เป็น Public API ทำให้นักวิจัยสามารถนำ Credentials นี้ไปใช้กับ ECR Internal API ได้

นักวิจัยจึงทำการทดลองส่ง Internal API 4 ตัวดังกล่าว ทำให้พบว่า Credentials ที่ได้มาจาก Cognito มีสิทธ์เขียน Public Image ใด ๆ ก็ได้ ชึ่งทำให้ช่องโหว่นี้อาจนำมาใช้โจมตีแบบ Supply chain attack กับ Public Image ที่มีผู้ใช้งานหลายล้านคนได้ ทาง Lightspin จึงได้รายงานช่องโหว่นี้กับทีม AWS Security

วิธีแก้ไข:

AWS ได้ทำการแก้ไขช่องโหว่ดังกล่าวเรียบร้อยแล้ว โดยที่ผู้ใช้งานไม่ต้องดำเนินการใด ๆ

ที่มา: blog.

พบช่องโหว่ ELB HTTP header smuggling บน AWS

นักวิจัย Andrea Brancaleoni จาก Brave Software พบช่องโหว่ HTTP header smuggling ใน AWS ELB เมื่อมีการเปิดใช้งาน ‘Legacy cache settings’ ซึ่งทำให้ผู้โจมตีสามารถ Overwrite Header ใดก็ได้ที่จะถูกส่งไปยัง Web server ด้านหลังของ Load balancer

รายละเอียดของช่องโหว่

เมื่อผู้โจมตีส่ง request เป็น HTTP/1 และเพิ่ม space หลัง header ‘X-Forwarded-For’ จะสามารถทำให้ inject header ใดๆก็ได้ลงใน ‘X-Forwarded-For’ จากนั้น AWS ELB จะนำค่าใน ‘X-Forwarded-For’ ที่ถูก inject มาแปลงเป็น header และส่งไปให้กับ Web server

ผลกระทบ

ผู้โจมตีสามารถจะปลอมแปลง IP address, CloudFront enhanced header ใดๆก็ได้

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

ปัจจุบัน AWS ได้ทำการอัปเดต Patch ของ ELB เรียบร้อยแล้วโดยที่ผู้ใช้งานไม่ต้องดำเนินการใดๆ

ที่มา: twitter.

นักวิจัยจาก 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.

นักวิจัยจาก Lightspin พบช่องโหว่ local file read ใน RDS และ Aurora PostgreSQL บน AWS โดยการใช้ third-party open-source PostgreSQL extension ที่ชื่อว่า “log_fdw” ปกติแล้ว log_fdw จะใช้ในการอ่านไฟล์ log ในเครื่อง RDS แต่นักวิจัยสามารถ Bypass การตรวจสอบชื่อไฟล์ของ log_fdw ทำให้สามารถอ่านไฟล์ใดก็ได้ในเครื่อง RDS

โดย RDS คือบริการ Database ที่ผู้ใช้งานไม่ต้องบริหารจัดการตัว OS, Database Patch หรือ Security Patch ทุกอย่างถูกจัดการให้โดย AWS จึงทำให้ปกติแล้วผู้ใช้งานจะไม่มีสิทธ์เข้าถึง OS โดยตรง หรือสิทธ์ Superuser ใน Database

ซึ่งนักวัจัยพบว่าเมื่อสามารถเข้าถึงไฟล์ RDS config ‘/rdsdbdata/config/postgresql.

นักวิจัยด้านความปลอดภัยจาก Palo Alto Networks พบ API ของ Amazon Web Services (AWS) มากกว่า 20 รายการที่สามารถนำไปใช้เพื่อรับข้อมูลของภายในขององค์กรและใช้ประโยชน์จากข้อมูลเพื่อทำการโจมตีเป้าหมายแบบกำหนดบุคคลที่อยู่ภายในองค์กร

นักวิจัยด้านความปลอดภัยระบุว่า API ที่มีช่องโหว่การโจมตีจะทำงานในพาร์ติชัน AWS ทั้งสามตัวคือ aws, aws-us-gov หรือ aws-cn โดยบริการ AWS ที่เสี่ยงต่อการละเมิด ได้แก่ Amazon Simple Storage Service (S3), Amazon Key Management Service (KMS) และ Amazon Simple Queue Service (SQS)

นักวิจัยกล่าวอีกว่าสาเหตุที่แท้จริงของปัญหาคือที่ถูกค้นพบคือแบ็กเอนด์ AWS จะทำการตรวจสอบ resource-based policies ทั้งหมดที่แนบมากับ resources เช่นบัคเก็ต Amazon Simple Storage Service (S3) และ customer-managed key โดยทั่วไปฟิลด์ Principal จะถูกรวมอยู่ใน resource-based policies เพื่อระบุผู้ใช้ที่มีสิทธิ์เข้าถึง อย่างไรก็ตามหากระบุข้อมูลประจำตัวที่ไม่มีอยู่ใน policy การเรียก API เพื่อสร้างหรืออัปเดต policy จะเกิดการล้มเหลวและผู้โจมตีสามารถใช้ฟีเจอร์เพื่อตรวจสอบข้อมูลประจำตัวที่มีอยู่ในบัญชี AWS

Palo Alto Networks ได้ออกคำเเนะนำให้ผู้ดูแลระบบทำการลบผู้ใช้ที่ไม่ได้ใช้งานออก ซึ่งจะทำให้ผู้โจมตีไม่สามารถคาดเดาชื่อผู้ใช้ได้โดยการเพิ่มสตริงแบบสุ่มใน log และ monitor identity authentication ทั้งนี้ผู้ดูแลระบบควรทำการเปิดใช้งาน Two-Factor authentication (2FA) ในการเข้าสู่ระบบเพื่อเป็นการป้องกันบัญชีผู้ใช้อีกทางหนึ่ง

ที่มา: securityweek.

นักวิจัยจาก Cado Security ได้เปิดเผยถึงการค้นพบที่เกี่ยวกับกลุ่มอาชญากรรมทางไซเบอร์ที่กำลังใช้ Crypto-Mining Worm ชนิดใหม่ที่เรียกว่า TeamTNT ใช้ทำการขโมย Credential และค่าคอนฟิกของ AWS ที่เก็บอยู่ในรูปแบบ Plaintext จาก Docker และ Kubernetes ที่ถูกบุกรุก

TeamTNT นั้นเป็นบอตเน็ตชนิด Cryptocurrency Mining ถูกค้นพบครั้งเเรกโดย MalwareHunterTeam และถูกวิเคราะห์เพิ่มเติมโดยทีมนักวิจัยจาก Trend Micro จากการวิเคราะห์เมื่อเซิร์ฟเวอร์ติดเชื้อ ตัวบอตเน็ตจะเรียกใช้ Masscan IP เพื่อทำการสแกนเนอร์พอร์ตหา Docker APIs และ Kubernetes ที่ทำการตั้งค่าคอนฟิกผิดพลาดและสามารถเข้าถึงได้เพื่อทำการติดตั้งตัวเองในคอนเทนเนอร์บนเซิร์ฟเวอร์ที่พบ จากนั้น TeamTNT จะสแกนระบบเพื่อหาไฟล์ที่ไม่ได้เข้ารหัสโดย AWS CLI เพื่อทำการขโมย Credentials และค่าคอนฟิกของ AWS ที่ถูกเก็บอยู่ในรูปแบบ Plaintext จากพาทที่เก็บข้อมูลคือ ~/.aws/credentials และ ~/.aws/config.

จากเหตุการณ์ที่ข้อมูลของ Capital One รั่วไหล กระทบลูกค้ากว่า 106 ล้านคน ในวันนี้ทีมตอบสนองการโจมตีและภัยคุกคาม (Intelligent Response) จากบริษัท ไอ-ซีเคียว จำกัด จะมาวิเคราะห์เหตุการณ์ข้อมูลรั่วไหลของ Capital One รวมถึงแนวทางในการรับมือค่ะ โดยจะประกอบไปด้วยหัวข้อดังนี้

Executive Summary
Incident Timeline
Possible Vulnerabilities and Flaws
Recommendation
References
AWS Case Study by Security Researcher

Executive Summary
Capital One Financial Corporation announced today that on July 19, 2019, it determined there was unauthorized access by an outside individual who obtained certain types of personal information relating to people who had applied for its credit card products and to Capital One credit card customers.

OCR Software ที่กำลังพัฒนาของ Abbyy ทำข้อมูลเอกสารลูกค้าจำนวน 200,000 ฉบับรั่วไหล เนื่องจากฐานข้อมูล MongoDB มีการรักษาความปลอดภัยไม่เพียงพอ

เมื่อวันที่ 19 สิงหาคม นักวิจัย Bob Diachenko ได้ค้นพบฐานข้อมูล MongoDB มีการตั้งค่าที่ผิดพลาดบนแพลตฟอร์มระบบคลาวด์ Amazon Web Services (AWS) มีขนาด 142GB และอนุญาตให้เข้าถึงได้โดยไม่ต้องเข้าสู่ระบบ ทำให้ผู้บุกรุกสามารถเข้าถึงไฟล์ลูกค้าได้

ฐานข้อมูลเก็บเอกสารที่สแกนโดยมีข้อมูลสำคัญ ได้แก่ สัญญาข้อตกลง ข้อมูลจดหมายภายในและบันทึกช่วยจำ รวมถึงไฟล์มากกว่า 200,000 ไฟล์ของลูกค้า Abbyy ที่สแกนข้อมูลและเก็บไว้ในระบบพร้อมใช้งานในระบบคลาวด์ หลักฐานบ่งบอกว่าฐานข้อมูลเป็นของ Abbyy มาจากชุดเอกสารที่มีชื่อผู้ใช้งาน Abbyy อยู่ในรูปแบบที่อยู่อีเมลของบริษัท และรหัสผ่านที่เข้ารหัส โดยกลุ่มลูกค้าของ Abbyy ชื่อดังมีอยู่ในหลายภาคส่วนเช่น Volkswagen, Deloitte, PwC, PepsiCo, Sberbank, McDonald's

Diachenko กล่าวว่าสองวันหลังจากการแจ้งเตือนของเขา ทีมรักษาความปลอดภัยที่ Abbyy ได้ทำการปิดการเข้าถึงข้อมูลดังกล่าวแล้ว

ที่มา: BLEEPINGCOMPUTER