Persistence Cookie: เรื่องเล็ก ๆ ในยุค Microservices ที่ไม่ควรมองข้าม
By Supawee Foitong,
Penetration Tester Team, Datafarm Company Limited
สวัสดีครับในบทความสำหรับวันนี้ มากับเรื่องเล็กๆ แต่ก็ไม่ควรมองข้ามกันดีกว่าครับ เคยได้ยินคำนี้ไหมครับ Persistence Cookie คิดว่าหลายๆคนอาจจะเคยได้ยินผ่านตากันมาบ้าง หรือหลายๆคนอาจจะเคยเปิด developer tools แล้วเห็น cookie แปลกๆชื่อ BIGipServer หรือ NSC_appservice แต่ไม่รู้ว่ามันคืออะไร และมีหน้าที่อะไร ทำไมมันถึงเป็นเรื่องเล็กๆน้อยๆที่ไม่ควรมองข้าม ถ้าๆเพื่อนๆมีเวลาสักเล็กน้อย แวะมาอ่านบทความนี้ก่อนได้นะครับ เพราะวันนี้ผมจะมาเล่าให้ฟังครับ ก่อนที่เราจะพูดถึงเรื่อง persistence cookie มันคืออะไร ทำหน้าที่อะไร เราต้องย้อนกลับไปดูบริบทของระบบในปัจจุบันก่อนครับ
ในยุคปัจจุบันที่หลายๆองค์กรส่วนใหญ่เปลี่ยนสถาปัตยกรรมระบบจาก Monolithic Architecture ไปสู่ Microservices Architecture หรือ การกระจายโหลด (Load Balancing) กลายเป็นองค์ประกอบพื้นฐานของระบบ Production แทบทุกแห่ง Web Application ไม่ได้ทำงานอยู่ในเครื่องเดียวอีกต่อไป แต่กระจายอยู่กับหลายๆ instance แทน หลาย Node หลาย Availability Zone และนี่คือจุดที่ Load Balancer หรือ Application Delivery Controller (ADC) เข้ามามีบทบาทสำคัญ หนึ่งใน Feature ที่ถูกใช้งานแทบทุกองค์กรคือ Session Persistence หรือ Sticky Session ซึ่งมักถูกมองว่าเป็นตัวช่วยด้านความเสถียรของระบบ
แต่ในมุมมองของผู้โจมตี (Attacker) Persistence Cookie อาจกลายเป็นแหล่งข้อมูลที่ช่วยเปิดเผยโครงสร้างภายในองค์กรโดยไม่ได้ตั้งใจ
- Load Balancer ทำงานอย่างไรในยุค Microservices
ถ้าจะให้เข้าใจภาพรวมง่ายๆ ในสถาปัตยกรรมแบบ Microservices โครงสร้างมักเป็นลักษณะนี้:
เมื่อมีหลาย Instance ก็ต้องมีตัวกลางมาช่วยจัดการ นั่นคือ Load Balancer หรือบางองค์กรใช้คำว่า Application Delivery Controller (ADC) ตัว Load Balancer มีหน้าที่หลักคือรับคำขอจากผู้ใช้ แล้วกระจายไปยัง Backend Server ตามเงื่อนไขที่กำหนด ไม่ว่าจะเป็น Round Robin, Least Connection หรือ Layer 7 Routing ตาม Path
ลองนึกภาพง่าย ๆ ว่าเรามี Backend 2 เครื่อง:
Server A — Instance 1
Server B — Instance 2
ผู้ใช้ส่งคำขอเข้ามา Load Balancer ก็เลือกหนึ่งในสองเครื่องนี้ไปประมวลผล
ปัญหาจะเกิดขึ้นเมื่อระบบมี “Session” เช่น การ Login หรือการเก็บตะกร้าสินค้า หากผู้ใช้ Login ผ่าน Server A แล้วคำขอถัดไปถูกส่งไป Server B ซึ่งไม่มี Session เดิมอยู่ใน Memory ผู้ใช้อาจถูก Logout หรือเกิด Error ได้
ตรงนี้เองที่ Sticky Session หรือ Session Persistence เข้ามามีบทบาท
Session Persistence คือกลไกที่ทำให้คำขอจากผู้ใช้คนเดิม ถูกส่งกลับไปยัง Backend เครื่องเดิมตลอดช่วง Session นั้น ๆ วิธีที่นิยมที่สุดคือการใช้ Cookie-Based Persistence หรือที่เราเรียกกันว่า Persistence Cookie
ลำดับการทำงานจะเป็นแบบนี้:
- ผู้ใช้เข้าเว็บครั้งแรก ยังไม่มี Persistence Cookie
- Load Balancer เลือก Backend เช่น 192.168.1.1:8080
- Load Balancer สร้าง Cookie แล้วส่งกลับไปที่ Browser
- ครั้งถัดไป Browser ส่ง Cookie ตัวนั้นกลับมา
- Load Balancer อ่านค่า Cookie แล้ว Route ไป Backend เดิม
- Session Persistence หรือ Sticky Session คืออะไร
สมมุติว่าเราทำการส่งข้อมูลไปยังระบบ แล้ว Load balancer ส่งต่อข้อมูลนั้นไปยัง instance 1 ของ service A เพื่อประมวลผลข้อมูล และเราจำเป็นที่จะต้องส่งข้อมูลอีกชุดเพื่อไปประมวลผล โดยที่ข้อมูลชุดนั้นจำเป็นที่ต้องทำงานต่อเนื่องจากชุดก่อนหน้า การที่เราส่งคำขอ (Request) ไปยัง Microservices นั้น หากไม่มี Session Persistence ไม่มีทางที่เลยที่ load balancer จะรู้ได้ว่า คำขอ (Request) ที่ส่งเข้ามานั้นต้องการส่งไป instance 1 เพื่อประมวลผลต่อจากข้อมูลก่อนหน้า
Session Persistence หรือ Sticky Session จึงเป็นตัว ที่กำหนดให้คำขอ (Request) จากผู้ใช้คนเดิมถูกส่งไปยังเว็บเซิร์ฟเวอร์ (Backend Server) เครื่องเดิมตลอดระยะเวลาการใช้งาน (Session) นั้นๆ เพื่อรักษาความต่อเนื่องของข้อมูล เช่น ตะกร้าสินค้า หรือสถานะการล็อกอิน โดยมักใช้คุกกี้หรือ IP ของผู้ใช้ในการจดจำ instance ที่จะไปนั่นเอง
โดยใน คำขอ (Request) จะมีการแนบ Persistence Cookie ที่เรากล่าวถึงที่ต้นบทความซึ่งมีรู้แบบนี้
```
<server_ip_encoded>.<port_encoded>.
```
โดยในแต่ละ vendor นั้นจะมีหน้าตาที่ต่างกันออกไปคลายๆแบบนี้
F5 BIG-IP (LTM)
```
Set-Cookie: BIGipServerAPPPOOL=16885952.36895.0000
```
Citrix ADC (NetScaler)
```
Set-Cookie: NSC_appservice=3139322e3136382e312e313a38303830
```
- จุดเล็กๆที่เราอาจะมองข้ามไป
ในข้างต้นที่กล่าวมาตัวของ persistence cookie ที่มีการส่งผ่าน คำขอ(request) นั้นมองผ่านๆก็อาจจะไม่มีอะไรดูแค่เป็นข้อมูลปกติที่ส่งกันแต่ในมุมมองของ Attacker นั้น cookie ตัวนี้ (ในบาง configuration) อาจจะเป็น 1 ในข้อมูลที่สำคัญซึ่งนำไปสู่การโจมในขั้นต่อๆไป
ตัวอย่าง
Set-Cookie: BIGipServerAPPPOOL=16885952.36895.0000
ถ้าเห็นแค่นี้ หลายคนอาจคิดว่าเป็นตัวเลขธรรมดา แต่จริง ๆ แล้วค่าตัวแรกและตัวที่สองมีความหมาย (ส่วนของ part นี้ถ้าเกิดว่าขี้เกียจคำนวนผมจะทิ้ง tools ไว้ให้ท้ายบทความนะครับ )
ในกรณีนี้ 16885952 คือค่า Decimal ของ IP Address หลังจากผ่านกระบวนการแปลงแบบ Little Endian ส่วน 36895 คือค่า Port ที่ถูกแปลงแล้วเช่นกัน
เมื่อเราแกะค่าออกมา เราจะได้:
```
192.168.1.1:8080
```
แปลว่าจาก Cookie เพียงตัวเดียว เราสามารถรู้ได้ว่า Backend Server ภายในองค์กรคือ IP อะไร และเปิด Port อะไรอยู่
อีกตัวอย่างหนึ่งคือระบบ Citrix ADC (NetScaler):
```
Set-Cookie: NSC_appservice=3139322e3136382e312e313a38303830
```
ค่าด้านหลังเป็น Hex Encoding ของ ASCII เมื่อ decode จะได้:
192.168.1.1:8080
กรณีนี้ยิ่งตรงไปตรงมากว่า เพราะเป็นเพียงการ encode ข้อความ IP:Port เป็น Hex เท่านั้น ไม่ได้มีการเข้ารหัสจริง
ทำให้ผู้โจมตี attacker นั้นได้รับข้อมูลจาก Persistence Cookie ว่า:
- ระบบใช้ Private IP ช่วงไหน
- Backend เปิด Port อะไร
ลองจินตนาการสถานการณ์ว่า ระบบมีช่องโหว่ SSRF หรือช่องโหว่ที่ทำให้ผู้โจมตีสามารถส่งคำขอจากภายในระบบได้ หากเขารู้แล้วว่า Backend อยู่ที่ IP ช่วงไหน เขาสามารถยิงคำขอไปยัง IP นั้นได้โดยตรง แทนที่จะต้องเดา Subnet ภายในใหม่ทั้งหมด
Persistence Cookie จึงมีคุณค่าในขั้น Reconnaissance หรือขั้นเก็บข้อมูลก่อนโจมตี
สรุป
แม้ persistence cookie ที่ถูกออกแบบมาเพื่อแก้ปัญหาเรื่อง Session Consistency ในระบบนั้น จะเป็นส่วนเล็กๆ แต่ก็ไม่ควรมองข้าม ต่อให้ไม่ได้เป็นปัญหาด้วยตัวมันเอง แต่ข้อมูลที่เปิดเผยออกมาอาจจะเป็นส่วนช่วยผู้โจมตี (Attacker ) ในการยึดระบบได้ ทั้งนี้อย่าลืมทำตาม best practice (เข้ารหัส persistence cookie) ตามคู่มือที่ให้มาด้วยนะเพื่อความปลอดภัย
- Tools
- F5 BIG-IP (LTM) (https://github.com/IBM/f5-bigip-decode/blob/main/bigip-decode.py)
- Citrix ADC (NetScaler) (https://github.com/catalyst256/Netscaler-Cookie-Decryptor/blob/master/nsccookiedecrypt.py)
Refferences
- https://aws.amazon.com/th/what-is/load-balancing/
- https://securiti.ai/blog/persistent-cookie/
- https://docs.netscaler.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-persistence/http-cookie-persistence.html
- https://techdocs.f5.com/en-us/bigip-14-0-0/big-ip-local-traffic-manager-implementations-14-0-0/configuring-http-load-balancing-with-cookie-persistence.html
