July 22, 2020

222 words 2 mins read

เรื่องเล่าของ 👉👩👈 | นี่มัน Pentest หรอคะ!?

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

เมื่อพูดถึงการประเมินว่าแอปพลิเคชันหรือเว็บปลอดภัยแค่ไหน เรามักจะนึกถึงคำว่า vulnerability assessement (VA) หรือการทำ pentest ใช่ไหมคะ ทั้งสองอย่างนี้เป็นสิ่งที่คล้ายกันแต่ก็ให้ผลลัพธ์ต่างกัน เพียงแต่ว่าสิ่งที่เรามักจะเห็นในวงการนี้คือการนำการประเมิน 2 แบบนี้มาใช้แทนกัน เช่น การขาย pentest แต่ดันทำเป็น VA ไปขาย! 😲 ซึ่งสร้างความเข้าใจผิดๆ ให้ลูกค้าว่าระบบนั้นไม่ปลอดภัยเพราะเจอช่องโหว่เยอะมากกกกก หรือปลอดภัยเพราะผล VA ไม่เจออะไรเลย (แต่ให้ที่อื่น pentest ต่อมันก็เจอนะ!?)

ตัวอย่างนึงที่เราจะมาดูกันวันนี้คือสิ่งทีน้องเจอมาเองค่ะ เรื่องคือ บ ของน้องได้เป็น vendor เขียน website ให้กับ บ ที่หนึ่ง จากนั้้น บ นั้นได้มีการทำ internal pentest และเจอว่าเว็บในความโอบอุ้มดูแลของน้อง มีช่องโหว่ที่ร้ายแรงมากๆ อยู่ ผลถูกส่งมาใน Report ที่ได้จาก Ac _ _ _ _ ix พร้อมกับคอมเม้นให้แก้ไขด่วนๆๆ ตามรูปด้านล่างค่ะ

สิ่งที่เห็นอยู่นี้คือรีพอร์ทช่องโหว่ Reflected XSS ที่ _ _ unet _ _ เจอใน Magento เราจะเห็น Ac _ _ _ _ ix ใช้วิธีสร้าง XSS payload แล้วเอามาเติมต่อท้าย URL ที่เราทดสอบ แล้วด้วยวิธีการบางอย่าง _ _ unet _ _ จะมีการหาว่า Payload ที่ใส่เข้าไปมีผลออกมามั้ย

Acunetix Result

เพียงแต่ว่าสิ่งที่เราทดสอบอยู่นั้นคือ Magento ซึ่งก็ถือว่ามีระบบป้องกันที่ดีในระดับนึงละแมะะะะ วิธีการที่ Magento ใช้ในการป้องกันอ้างอิงจากปากคำของหนึ่งใน expert ด้านการแฮกแห่งกลุ่มส้วมที่ได้อธิบายไว้เมื่อรวมกับ payload ที่ Ac _ _ _ _ ix คือ 4Juo='nn9s([!+!])'E76= จะกลายเป็น

https://www.ggfakenaka.com/about-us?"4Juo='nn9s([!+!])'E76="

ในเบื้องหลัง payload ด้านบนจะถูกใช้ตามตัวอย่างด้านล่าง

Magento Escaping

จะเห็นว่า " ก็ถูก escape ด้วยเครื่องหมาย \ แล้ว ทำให้ไม่ว่าจะใส่อะไรไป browser ก็จะมองเป็น string ไม่ได้มองเป็น HTML tag หรือ JavaScript ที่อันตราย

ดังนั้นมันไม่ควรที่จะถูกเรียกว่าช่องโหว่ได้!!! 🙅

ความอิหยังวะที่มากกว่านั้นก็คือ สิ่งที่ทำให้ Ac _ _ _ _ ix มองว่าเหตุการณ์นี้เป็นช่องโหว่นั้นคือการทำ pattern matching ง่ายๆ ซึ่งทำให้ผลลัพธ์ไม่ควรถูกมองว่าเป็นช่องโหว่ กลับถูกมองว่าเป็นช่องโหว่ และทำให้ผลเป็น false positive นั่นเอง 🤷

หากใครที่จ้าง pentest แต่ได้รีพอร์ตซึ่งดูเหมือนถูกเจนจากโปรแกรมมาพร้อมกับรายการช่องโหว่เยอะๆๆๆ เกินจะแก้ไหว อาจเป็นไปได้นะคะว่าสิ่งที่คุณถืออยู่นั้นคือรีพอร์ต VA ที่ถูกหลอกขายในบริการ pentest นั่นเอง เพราะในความจริงแล้ว pentest ควรเป็นการจำลองการโจมตีซึ่งเน้นไปที่การแสดงให้เห็นถึงผลกระทบที่อาจเกิดขึ้น ไม่ใช่เพียงแค่ใส่ <script>alert(1);</script> แล้วบอกว่าเป็นช่องโหว่แล้ว 😤

ไม่ใช่ความเสี่ยงทุกอันที่เป็นช่องโหว่ และไม่ใช่ช่องโหว่ทุกอันที่เอามาแฮกและสร้างผลกระทบได้!!!! 😡

ลองถามตัวเองดูนะครับว่าถ้าแอพพลิเคชั่นมีช่องโหว่ที่สามารถข้าม phase การจ่ายเงินได้เลยโดยการยิง request ของ phase สุดท้ายโดยตรง ซึ่งเป็นช่องโหว่ที่ automated tool หาไม่เจอแน่ๆ คุณยังโอเคกับการทำ pentest ด้วยการใช้ tool สแกนอย่างเดียวอยู่ไหม ??? – Golf

สำหรับบางคนคงจะชอบที่ VA = pentest มากกว่า มันทำงานง่ายดี – Gun

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

อยากรู้จังเลยค่ะว่าวงการซีเคียวริตี้ประเทศไทยจะเป็นยังไงต่อ เราจะยังหลอกบอกลูกค้าไปต่อมั้ยว่าการทำ VA นั้นเป็น pentest แล้วเราจะยังเอารีพอร์ต VA ไปส่งเป็นผล pentest อยู่อีกหรือป่าว ติดตามกันต่อไปนะคะ! 🥰 – GeeGee