Network Security – Page 8 – CoP PSU IT Blog

วิธีใช้งาน Kali Linux – OWASP Zap – User Authentication

October 19, 2016 14:48

ในการตรวจสอบ Web Application ที่ต้องมีการ Authentication โดยใช้งานผ่าน Web Form จะต้องกำหนดค่าให้ OWASP Zap รู้ว่า จุดใดเป็น Login Form และ Field ใดที่ใช้เป็น Username และ Password ก่อน หลังจากนั้น จะสามารถกำหนดได้ว่า จะโจมตีด้วย Username ใดบ้าง เพื่อใช้ในการทดสอบ ขั้นตอนในการตั้งค่าและโจมตีมีดังนี้ ใน Web Browser ให้ตั้งค่า Proxy เป็น 127.0.0.1 Port 8080 ทำการเปิด Web Page ที่ต้องการโจมดี โดยให้ทำเป็น Login ตามปรกติ ด้วย Username/Password ที่ใช้งานได้จริง เมื่อ Login สำเร็จแล้ว จะได้หน้าตาประมาณนี้ จากนั้น กลับไปที่ OWASP Zap จะเห็นว่าใน Sites มี URL ของ Website ที่ต้องการโจมตีปรากฏอยู่ จากนั้นให้ คลิกขวาที่ URL ที่ต้องการโจมตี คลิก Include in Context > Default Context จะปรากฏหน้าต่าง Session Properties ให้ทราบว่า จะใช้งาน URL นี้ ให้คลิกปุ่ม OK จากนั้นให้คลิก POST Action ที่เป็นการส่งข้อมูลการ Login ผ่าน Web Form แล้ว คลิกขวา เลือก Flag as context > Default Context : Form-based Auth login Request จะปรากฏหน้าต่าง Session Properties อีกครั้ง ให้ทราบว่า จะใช้ Login Form Target URL และ Login Request POST DATA ดังภาพ ให้กำหนดว่า Username Parameter และ Password Parameter คือ Field ใด จากนั้น ให้คลิกปุ่ม OK จากนั้น ให้คลิก Tab Response ของ POST Action ที่ใช้ในการ Login แล้วมองหา ข้อความ ที่จะให้ OWASP Zap ค้นหา เพื่อเป็นการยืนยังว่า สามารถ Login ได้แล้ว จากนั้น คลิกขวา แล้วเลือก Flag as Context > Default Context: Authentication Logged-in indicator จะปรากฏหน้าต่าง Session Properties อีกครั้ง ให้ทราบว่า Regex pattern identified in Logged in response message คือคำใด จากนั้น ให้คลิกปุ่ม OK จากนั้น คลิก Users ด้านซ้ายมือ แล้ว คลิก เครื่องหมายถูก หน้า Username ที่จะใช้ในการ Login จากนั้น คลิก Forced Users ด้านซ้ายมือ แล้วเลือก User ที่จะใช้ในการโจมตี แล้วคลิก OK

วิธีใช้งาน Kali Linux – OWASP Zap – Active Scan

October 17, 2016 11:17

ใน Kali Linux มีเครื่องมือ Web Application Security Scanner ที่น่าสนใจตัวหนึ่ง คือ OWASP Zap (Open Web Application Security Project) เหมาะสำหรับการใช้งานตั้งแต่การทดสอบเบื้องต้น ไปจนถึงการโจมตีขั้นสูงได้ *** คำเตือน : อย่าใช้เครื่องมือนี้กับระบบคอมพิวเตอร์ที่ท่านไม่ใช่เจ้าข้องเด็ดขาด *** ในบทความนี้ จะแสดงขั้นตอนการทดสอบ Web Application โดยใช้กระบวนการ Active Scan ใน Kali Linux เปิด Applications > 03 Web Application Analysis > owasp-zap เลือก No, I do not want to persist this session at this moment in time แล้วคลิก Start (ยังไม่ต้องใช้ในตอนนี้) ในช่อง URL to attack ใส่ URL ของ Web Application ที่ต้องการทดสอบ แล้วคลิก Attack ระบบจะทำการ Spider และ Active Scan ตามลำดับ ผลที่ได้ “ในเบื้องต้น” ก็จะแค่แสดงในส่วนของ Alerts ทั่วไปเกี่ยวกับการตั้งค่าที่อาจจะไม่เหมาะสม เช่น X-Frame-Options Header ไม่ได้ตั้งค่าไว้, มีการใช้ Private IP, ไม่ได้ป้องกัน XSS และอื่นๆเป็นต้น เนื่องจากเครื่องที่ทำการทดสอบนี้ จริงๆแล้ว มี Directory ย่อยๆ ลงไปอีกมากมาย ที่ไม่ได้ชี้ Link ไปจาก index.php ในหน้าแรกของ Web Site วิธีการที่จะให้ OWASP ZAP กวาดไฟล์เดอร์ย่อยๆออกมา ใช้คลิกขวาที่ Sites ที่ต้องการ แล้ว Attack > Forced Browse site จากนั้นจะปรากฏ Forced Browse Tab ขึ้นมา ให้เลือก directory-list-1.0.txt ซึ่งจะทำการ Brute Force ชื่อ Directory ที่เค้าไปเก็บรวบรวมมา จากนั้น ทำการ Attack ด้วย Spider อีกครั้ง จากนั้น ทำการ Attack ด้วย Active Scan อีกครั้ง แต่ให้ตั้งค่าใน Policy Tab ดังภาพ เพื่อให้ Threshold เป็น High และ Strength เป็น Insane (จะอธิบายละเอียดอีกครั้งในบทความต่อไป) คลิก Go ทั้ง 2 บรรทัด แล้วคลิก Start Scan ดูผลการ Scan ได้ที่ Alerts Tab ดังตัวอย่างพบว่ามีช่องโหว่สำคัญคือ Cross Site Scripting (Reflected), Path Traversal และ Remote File Inclusion โดยบอกวิธีการ Attack ที่ใช้ในการทดสอบ และวิธีการแก้ไขพร้อม จะกลับมาอภิปราย และอธิบายรายละเอียดอีกครั้งในบทความต่อไป References: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project https://github.com/zaproxy/zap-core-help/wiki https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project

อย่าเชื่อ Tools จนเกินไป : กรณี joomscan

October 12, 2016 17:04

ได้ยินหลายคนพูดถึงการใช้งานตรวจสอบ Website โดยเฉพาะ Joomla โดยใช้เครื่องมือที่ชื่อว่า joomscan ก็เลยลองติดตั้ง และ ทำการทดสอบกับ Web Server ใน VirtualBox ที่มีช่องโหว่ JCE ที่เจาะได้แน่ๆ เพื่อดูว่าเครื่องมือนี้ทำงานอย่างไร ทำการโจมตีจาก Kali Linux ไปยังเครื่องเป้าหมาย ด้วย joomscan รายงานผลแจ้งว่า joomscan มีการ Update ล่าสุด เมื่อ Oct 22, 2012 นั่นคือเมื่อ 4 ปีที่แล้ว รายผลที่แจ้งช่องโหว่ ที่เจาะได้ มีดังนี้ แสดงให้เห็นว่า ด้วย Tools ตัวเดียวอาจจะไม่สามารถมั่นใจได้ว่า ระบบของเราปลอดภัยหรือไม่ ฝากไว้พิจารณาครับ

วิธีตรวจสอบเว็บไซต์ที่โดน Hack #18

August 1, 2016 15:24

ได้รับแจ้งจาก ThaiCERT ว่ามีเว็บไซต์ภายในโดเมนของมหาวิทยาลัย เผยแพร่ Code อันตราย ดังต่อไปนี้ จึงเข้าทำการตรวจสอบในเครื่องเว็บเซิร์ฟเวอร์ดังกล่าว พบการวางไฟล์ Backdoor ไว้ดังที่อธิบายใน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #17 แล้ว แต่ที่เห็นผิดปรกติ ก็เป็นใน access.log ของ Apache ซึ่งพบว่า มีการเรียกใช้ xmlrpc.php เป็นจำนวนมาก ดังภาพ จากการตรวจสอบ พบว่า xmlrpc.php เป็นช่องทางให้สามารถเรียกใช้ Function ต่างๆผ่านทาง HTTP และเป็นช่องทางให้ App ต่างๆสามารถติดต่อกับ WordPress ได้ แต่ก็เป็นช่องทางให้เกิดการเดารหัสผ่านจำนวนมากได้เช่นกัน (Brute Force Attack) โดยสามารถทดลอง ส่ง XML ที่มีโครงสร้าตามที่ API กำหนด เช่น wp.getUsersBlogs [1][2][3] สามารถดูจำนวน Blog ที่ User คนนั้นๆเขียนขึ้นมา แต่ ต้องระบุ username/password ซึ่งตรงนี้จะเป็นส่วนที่ทำให้เกิดการ Brute Force ได้ ด้วยคำสั่งต่อไปนี้ เป็นการเดารหัสผ่านไปยัง http://localhost/blog/xmlrpc.php echo “<methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value> <string>admin</string></value></param> <param><value><string>password</string></value></param></params></methodCall>” | POST http://localhost/blog/xmlrpc.php หากสำเร็จ จะได้คำตอบมาอย่างนี้ หากเป็น WordPress รุ่นต่ำกว่า 4.0 เปิดให้ใช้ system.multicall ซึ่งทำให้สามารถเดารหัสผ่านจำนวนมาก ใน 1 Request ทำให้ระบบตรวจจับได้ยาก ดังนั้น หากไม่จำเป็นต้องใช้ xmlrpc.php ก็สมควรปิดการใช้งานที่ระดับ Apache โดยสร้างไฟล์ /etc/apache2/conf-enabled/xmlrpc.conf มีข้อมูลเป็น <FileMatch “xmlrpc\.php$”> Order Deny,Allow Deny from All </FileMatch> จากนั้น Restart Apache ก็สามารถปิดการทำงานได้ Reference [1] http://www.hackingsec.in/2014/08/wordpress-xml-rpc-brute-force-attack.html# [2] http://blog.dewhurstsecurity.com/2012/12/11/introduction-to-the-wordpress-xml-rpc-api.html [3] https://codex.wordpress.org/XML-RPC_WordPress_API

วิธีตรวจสอบเว็บไซต์ที่โดน Hack #17

July 29, 2016 15:31

ปัจจุบันพบว่า รูปแบบของ Backdoor เปลี่ยนไป จากเดิมเป็น Base64 ซึ่งสามารถตรวจจับได้จาก Pattern ของ eval และ base64_decode ไปเป็น การใช้ eval ร่วมกับการใช้เทคนิคที่เรียกว่า Obfuscate หรือ การทำให้ PHP Code ปรกติ แปลงไปเป็นรูปแบบที่ซับซ้อนยิ่งขึ้น ทำให้การตรวจสอบด้วยเทคนิคเดิมไม่เจอ จาก วิธีตรวจสอบเว็บไซต์ที่โดน Hack #2 แสดงให้เห็นรูปแบบเดิม ดังภาพ จะเปลี่ยนมาเป็นแบบนี้ ดังนั้น อาจจะต้องปรับเปลี่ยนคำสั่งในการค้นหาเป็น find /var/www -name “*.php” -user www-data -type f | xargs grep GLOBAL แต่ก็พบว่า มีการซ่อน base64_decode ในรูปแบบนี้ก็มี ถึงแม้จะเลี่ยงการใช้ base64_decode ตรงๆแต่ก็ยังต้องใช้ eval อยู่ดี ดังนั้น จึงต้องใช้คำสั่งต่อไปนี้ในการค้นหา find /var/www -name “*.php” -user www-data -type f | xargs grep eval > eval.txt ซึ่งอาจจะได้ไฟล์มาจำนวนมาก ทั้งทีใช่และไม่ใช่ Backdoor เก็บไว้ในไฟล์ eval.txt ดังภาพ จึงต้องใช้วิธี แก้ไขไฟล์ eval.txt ดังกล่าว โดยลบบรรทัดที่ไม่ใช่ Backdoor ออก ให้เหลือแต่บรรทัดที่น่าสงสัยว่าจะเป็น Backdoor ไว้ แล้ว Save จากนั้นใช้คำสั่งต่อไปนี้เพื่อเก็บไฟล์ทั้งหมดไว้ก่อน ในไฟล์ suspect.tar.gz cut -d: -f1 eval.txt | xargs tar -zcvf suspect.tar.gz จากนั้น ทำ List ของไฟล์ที่ต้องเข้าตรวจสอบจริงๆ เก็บในไฟล์ชื่อ eval2.txt ด้วยคำสั่ง cut -d: -f1 eval.txt > eval2.txt แล้วจึงแก้ไขไฟล์ หรือ ลบทิ้งต่อไป