เจาะลึกความเสี่ยง: เมื่อข้อมูลลับ AWS รั่วไหลทางฝั่งไคลเอนต์
โลกของแอปพลิเคชันยุคใหม่พึ่งพาบริการคลาวด์อย่างมาก หนึ่งในนั้นคือ AWS ที่มีเครื่องมือและบริการหลากหลาย ทว่าการพัฒนาที่เร่งรีบ บางครั้งอาจนำไปสู่ช่องโหว่ที่คาดไม่ถึง โดยเฉพาะอย่างยิ่งการรั่วไหลของข้อมูลลับอย่าง AWS credentials ผ่านช่องทางฝั่งไคลเอนต์
เป็นภัยคุกคามที่เกิดขึ้นได้จริงและสร้างความเสียหายอย่างมหาศาลหากตกไปอยู่ในมือของผู้ไม่ประสงค์ดี
ทำความเข้าใจช่องโหว่ทางฝั่งไคลเอนต์
เมื่อพูดถึง client-side traffic เรากำลังพูดถึงข้อมูลทั้งหมดที่เบราว์เซอร์ของผู้ใช้งานรับส่งกับเซิร์ฟเวอร์ หรือ API ต่างๆ การสื่อสารเหล่านี้มักถูกมองข้ามว่าเป็นจุดที่ปลอดภัย แต่ในความเป็นจริงแล้ว ข้อมูลสำคัญจำนวนมากอาจถูกเปิดเผยได้ที่นี่
นักพัฒนาบางคนอาจเผลอเขียนโค้ด JavaScript ที่ฝังข้อมูลลับ หรือมีการเรียกใช้ API ที่ส่งผ่านข้อมูลยืนยันตัวตนต่างๆ อย่างไม่ระมัดระวัง ทำให้ผู้ที่เข้ามาเยี่ยมชมเว็บไซต์สามารถตรวจสอบและดึงข้อมูลเหล่านั้นไปได้ง่ายๆ
แกะรอยข้อมูลลับในเว็บแอปพลิเคชัน
การค้นหาข้อมูลลับเหล่านี้ไม่ใช่เรื่องยาก หากรู้วิธีและเครื่องมือที่เหมาะสม เครื่องมือสำหรับนักพัฒนา (Developer Tools) ที่มีอยู่ในเบราว์เซอร์แทบทุกตัว คือจุดเริ่มต้นที่ดี โดยเฉพาะแท็บ “Network” ที่จะแสดงทุกคำขอและการตอบกลับระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์
สิ่งที่เราควรมองหาคือ API calls ที่ดูเหมือนจะเกี่ยวข้องกับบริการคลาวด์ โดยเฉพาะ AWS
ลองสังเกตจาก Headers ของ Request และ Response เช่น X-Amz-Security-Token, Authorization, หรือ X-Amz-Date ซึ่งมักเป็นสัญญาณบ่งบอกถึงการใช้งาน AWS API นอกจากนี้ การตรวจสอบในไฟล์ JavaScript ก็เป็นสิ่งสำคัญ เพราะอาจมีการ hardcode AWS credentials ไว้โดยไม่ได้ตั้งใจ
ทำความรู้จัก AWS Credentials และอันตรายจากการรั่วไหล
เมื่อพบข้อมูลที่น่าสงสัย สิ่งที่เรามักจะเจอคือชุดของ AWS credentials ซึ่งประกอบด้วยสามส่วนหลัก:
Access Key ID (AKID) คือรหัสที่ระบุตัวตนของผู้ใช้หรือแอปพลิเคชัน
Secret Access Key (SAK) เปรียบเสมือนรหัสผ่านสำหรับ AKID เป็นข้อมูลที่ต้องเก็บเป็นความลับสูงสุด
และ Session Token (ถ้ามี) ซึ่งเป็นโทเค็นชั่วคราวที่ใช้ควบคู่กับ AKID และ SAK มักถูกสร้างขึ้นเมื่อมีการใช้ IAM Roles หรือ Federated Identity
หากข้อมูลเหล่านี้รั่วไหล ผู้ไม่หวังดีสามารถใช้มันเพื่อเข้าถึงทรัพยากร AWS ขององค์กร เช่น ถังเก็บข้อมูล S3, ฐานข้อมูล DynamoDB, หรือแม้แต่ควบคุมบริการอื่นๆ ทั้งหมด ทำให้เกิดความเสียหายร้ายแรงต่อข้อมูลและระบบ
ใช้ประโยชน์จากข้อมูลที่พบ: การเข้าถึงทรัพยากร AWS
เมื่อได้ AWS credentials มาแล้ว การใช้ AWS Command Line Interface (CLI) เป็นเครื่องมือที่มีประสิทธิภาพในการเข้าถึงและจัดการทรัพยากร โดยสามารถตั้งค่าได้ง่ายๆ
ตั้งค่าผ่าน Environment Variables โดยการ export AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, และ AWS_SESSION_TOKEN (ถ้ามี) พร้อมระบุ Region ของ AWS ที่เกี่ยวข้อง
หลังจากนั้น ก็สามารถเริ่มสำรวจได้ทันที
สำรวจและดึงข้อมูลจาก AWS DynamoDB
หนึ่งในเป้าหมายที่มักถูกโจมตีคือฐานข้อมูล AWS DynamoDB ซึ่งเป็น NoSQL database ที่นิยมใช้งาน การสำรวจเริ่มต้นด้วยการตรวจสอบสิทธิ์ที่ได้มาว่าสามารถทำอะไรได้บ้าง
สามารถใช้คำสั่ง aws dynamodb list-tables เพื่อดูรายการตารางทั้งหมดที่เข้าถึงได้
จากนั้น ใช้ aws dynamodb describe-table --table-name <ชื่อตาราง> เพื่อทำความเข้าใจโครงสร้างของตาราง เช่น คีย์หลักและแอตทริบิวต์ต่างๆ
สุดท้าย หากต้องการดึงข้อมูลทั้งหมดจากตาราง ก็ใช้ aws dynamodb scan --table-name <ชื่อตาราง> เพื่อเรียกข้อมูลออกมา การทำความเข้าใจโครงสร้างข้อมูลใน DynamoDB จะช่วยให้ค้นหาสิ่งที่ต้องการได้ง่ายขึ้นมาก
การป้องกันข้อมูล AWS รั่วไหล
ภัยคุกคามจากการรั่วไหลของ AWS credentials ทางฝั่งไคลเอนต์นั้นร้ายแรง แต่สามารถป้องกันได้ด้วยแนวทางปฏิบัติที่ดี
สำคัญที่สุดคือ หลีกเลี่ยงการ hardcode credentials โดยเด็ดขาดในโค้ดฝั่งไคลเอนต์ หรือแอปพลิเคชันที่เข้าถึงได้จากภายนอก ควรใช้ IAM Roles ที่กำหนดสิทธิ์อย่างจำกัด และใช้ Temporary Credentials ผ่าน AWS Security Token Service (STS)
พิจารณาการใช้ AWS Secrets Manager หรือ AWS Parameter Store สำหรับการจัดเก็บและเรียกใช้ข้อมูลลับอย่างปลอดภัย และตรวจสอบโค้ดรวมถึง dependency ต่างๆ อย่างสม่ำเสมอ เพื่อให้แน่ใจว่าจะไม่มีข้อมูลสำคัญใดๆ ถูกเปิดเผยโดยไม่ได้ตั้งใจ