Tag: Joomla

  • การเชื่อมต่อ OAuth2 ด้วย Joomla

    อยาก  Login ด้วย OAuth2 กับ Joomla ต้องทำอย่างไร

                 สำหรับตัวอย่างนี้จะทำการติดตั้งบน Joomla 3.9.3 ผ่าน Plugin MiniOrange OAuth Client

    • หลังจากติดตั้ง Joomla เสร็จ เข้าหน้า Administrator แล้วทำการกด Install เพื่อเข้าไปยังหน้าติดตั้ง Extension เพิ่มเติม

    • หลังจากนั้นกด Add Install from Web

    • ค้นหาชื่อ oauth

    • ติดตั้ง miniOrange OAuth Client 

    • หลังจากติดตั้งเสร็จให้ทำการเปิด Plugins เพิ่มเติมดังรูป

    • จากนั้นทำการตั้งค่าโดยสำหรับ miniOrange ต้องสมัครใช้งานก่อน เพราะมีทั้งแบบฟรีและไม่ฟรี แต่เราจะใช้เฉพาะในส่วนของฟรี

    • ในการสมัครต้องใส่ email และตั้งรหัสผ่าน

    • หลังจากติดตั้ง Joomla เสร็จให้ทำการกด Install เพื่อเข้าไปยังหน้าติดตั้ง Extension เพิ่มเติม

    • จากนั้นทำการตั้งค่าเกี่ยวกับ OAuth

    • สามารถกดทดสอบการ Authen ได้ที่ปุ่ม Test Configuration

    • จะปรากฎหน้า Login เพื่อเข้าสู่ระบบ

     

    •  

    • หลังจาก Login เสร็จจะคืนค่า User Profile ดังรูป

              ในการเอาไปใช้งานต่อให้ทำการสร้างปุ่ม ชี้ไปยัง http://localhost/joomla/?morequest=oauthredirect&app_name=other เพื่อเข้าใช้งาน OAuth ลองไปทำต่อดูครับ

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

    เทคนิคนี้ ใช้ผ่าน Internet Information Services (IIS) Manager โดยการแก้ไข Request Filtering ในระดับ Web Server เลย โดยดำเนินการตามวิธีการต่อไปนี้

    1. เรียก Command ด้วย การกดปุ่ม Windows + R แล้ว พิมพ์ inetmgr แล้วกดปุ่ม Enter
    2. คลิกเว็บเซิร์ฟเวอร์ของเครื่องที่ต้องการใน Connection Tab (ตัวอย่างในภาพ คลิกที่ WUNCAWEBSEC)
    3. ต่อไป ภายใต้หัวข้อ IIS ให้ Double-Click ที่ Request Filtering
    4. คลิกที่ Rules tab
    5. เพิ่มกฏสำหรับ JCE Bot
      ซึ่ง ไม่ต้องการให้ PHP ทำงานภายใต้ URL ซึ่งมีข้อความว่า “images/stories”
      โดย ไปที่ Action ด้านขวามือ แล้ว คลิกที่ Add Filtering Rules …
      แล้วใส่ข้อมูลตามภาพ แล้วคลิกปุ่ม OK

    1. เพิ่มกฏสำหรับ Upload โฟลเดอร์
      ซึ่ง ไม่ต้องการให้ PHP ทำงานภายใต้ URL ซึ่งมีข้อความว่า “upload”
      โดย ไปที่ Action ด้านขวามือ แล้ว คลิกที่ Add Filtering Rules …
      แล้วใส่ข้อมูลตามภาพ แล้วคลิกปุ่ม OK
    2. ผลที่ได้ใน Rules tab

    ทดสอบผลการทำงาน

    สมมุติเดิมโดนวางไฟล์ Backdoor ไว้ที่

    http://localhost/corin/images/stories/backdoor.php

    แต่เมื่อตั้ง Rules ดังกล่าวแล้ว จะทำให้ Hacker ไม่สามารถเรียกใช้งาน PHP ที่วางไว้ใน images/stories ได้ โดยจะได้ Error เช่นนี้

    วิธีนี้มีข้อดีคือ สามารถป้องกันการใช้งาน PHP ใน images/stories (และใน upload โฟลเดอร์) แต่ยังสามารถเรียกไฟล์ภาพและไฟล์อื่นๆได้ตามปรกติ เช่น

    http://localhost/corin/images/stories/clownspin.gif

    ลองใช้งานดูครับ 😉

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

    บทความนี้ จะกล่าวถึง วิธีการปิดช่องโหว่ของ Apache ที่ให้บริการ Web Hosting เลย เผื่อมีผู้ใช้ ติดตั้ง Joomla และมี JCE รุ่นที่มีช่องโหว่ จะได้ไม่สร้างปัญหา และ แนะนำวิธีสำหรับผู้พัฒนาเวปไซต์เองด้วย ที่เปิดให้มีการ Upload ไฟล์โดยผู้ใช้ผ่านทาง Web ด้วย … เพราะหน้าที่นี้ ควรเป็นของ Web Server Administrator ไม่ใช่ของ Web Master หรือ Web Author ครับ

    จากปัญหาช่องโหว่ของ JCE Exploited ของ Joomla ที่อธิบายไว้ใน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #3 ที่อธิบายขั้นตอนการเจาะช่องโหว่, วิธีตรวจสอบเว็บไซต์ที่โดน Hack #4 ซึ่งเป็นวิธีการตรวจสอบค้นหา และทำลาย Backdoor และ วิธีตรวจสอบเว็บไซต์ที่โดน Hack #11  วิธีการ Incremental Backup ซึ่งสามารถช่วยกู้ไฟล์ได้และรู้ว่า มีไฟล์แปลกปลอมอะไรเกิดบ้าง ซึ่งเป็นการแก้ปัญหาปลายเหตุทั้งสิ้น

    ส่วน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #5 กล่าวถึงการตรวจสอบว่า Software ที่ใช้งานอยู่มีช่องโหว่อะไรบ้าง ด้วยการตรวจสอบ CVE เป็นต้น

    สำหรับ JCE Exploited จะพบว่า การวางไฟล์ Backdoor จะเริ่มวางไว้ที่ไดเรคทอรี่ images/stories ที่ แกล้งเป็นไฟล์ .gif แล้วเอาโค๊ด PHP เข้ามาใส่ แล้วเปลี่ยนนามสกุลเป็น .php ภายหลัง ดังนั้น หาก Apache Web Server สามารถ ปิดกั้นตั้งแต่จุดนี้ได้ กล่าวคือ ต่อให้เอาไฟล์มาวางได้ แต่สั่งให้ทำงานไม่ได้ ก็น่าจะปลอดภัย และ หากพัฒนาเวปไซต์เอง หรือ ผู้ใช้ของระบบต้องการให้ Upload ไฟล์ไว้ในไดเรคทอรี่ใดได้ ก็ต้องแจ้งให้ Web Server Administrator รับทราบ และเพิ่มเติมให้ น่าจะทำให้ปลอดภัยมากขึ้นได้

    สมมุติฐานคือ

    1. ติดตั้ง OS และ Apache Web Server ใหม่

    2. ติดตั้ง Joomla ใหม่ หรือ เอา Web Application ที่ปลอดช่องโหว่อื่นๆ/Backdoor มาลง
      โดย Joomla ที่มีที่วางไฟล์ภาพไว้ที่ images/stories ส่วน Web Application อื่นๆ ขอสมมุติว่าตั้งชื่อไดเรคทอรี่ว่า uploads

    สำหรับ Apache2 บน Ubuntu Apache 2.2 นั้น มีโครงสร้างไดเรคทอรี่ดังนี้

    /etc/apache2/
    |-- apache2.conf
    |       `--  ports.conf
    |-- mods-enabled
    |       |-- *.load
    |       `-- *.conf
    |-- conf.d
    |       `-- *
    |-- sites-enabled
            `-- *

    เมื่อ Apache เริ่ม (Start) ก็จะไปอ่าน /etc/apache2/apache2.conf ในนั้น จะกำหนดภาพรวมของระบบ ได้แก่ ใครเป็นคน Start (APACHE_RUN_USER/APACHE_RUN_GROUP), การกำหนดชื่อไฟล์ .htaccess ที่เปิดให้ผู้ใช้ปรับแต่ง Apache ที่แต่ละไดเรคทอรี่ของตนได้, กำหนดว่า จะเรียกใช้ Module อะไรบ้าง โดยการ Include *.load, *.conf  จาก mods-enabled, กำหนดว่า จะเปิดให้มี Virtual Host อะไรบ้างโดยการ Include ไฟล์จาก sites-enabled และ ที่สำคัญ ผู้ดูแลระบบสามารถแยกไฟล์ config ออกเป็นส่วนย่อยๆเป็นไฟล์ โดยการ Include จาก conf.d

    ต่อไป สร้างไฟล์ /etc/apache2/conf.d/jce มีเนื้อหาดังนี้

    <DirectoryMatch ".*/images/stories/.*">
    <FilesMatch "\.php$">
           Order Deny,Allow
           Deny from All
     </FilesMatch>
    </DirectoryMatch>

     และในทำนองเดียวกัน สร้างไฟล์ /etc/apache2/conf.d/uploads มีเนื้อหาดังนี้

    <DirectoryMatch ".*/uploads/.*">
    <FilesMatch "\.php$">
           Order Deny,Allow
           Deny from All
     </FilesMatch>
    </DirectoryMatch>

    ก่อนจะ Restart/Reload Apache ทดสอบสร้างไฟล์ใน

    /var/www/joomla15/images/stories/0day.php
    /var/www/mywebapp/uploads/hack.php

    เมื่อเรียก URL
    http://localhost/joomla15/images/stories/0day.php

    http://localhost/mywebapp/uploads/hack.php

     ผลที่ได้คือ Backdoor หน้าตาประมาณนี้

    แต่พอใช้ Reload Apache ด้วยคำสั่ง

     sudo /etc/init.d/apache2 reload

     แล้วเรียก URL

     http://localhost/joomla15/images/stories/0day.php

     จะได้ผลดังนี้

    เป็นอันว่า แม้ Hacker จะสามารถเอาไฟล์ 0day.php ไปวางใน images/stories ได้ แต่ก็จะไม่สามารถทำงานได้ (อย่างน้อย ก็เรียกใช้ไม่ได้ แต่ผู้ดูแลต้องค้นหาและทำลายเป็นประจำ)

     อธิบายเพิ่มเติมเกี่ยวกับ Apache Configuration เล็กน้อย, การเขียนนั้น ประกอบด้วยสิ่งที่เรียกว่า Directive โดยแบ่งออกเป็น Container และ Directive ทั่วไป

    1. Container Directive: เป็นตัวบอกขอบเขต แบ่งออกเป็น

    1.1 FileSystem: ได้แก่

    1.1.1 <Directory directory-path> … </Directory>
    ตั้งค่ากับเฉพาะ ขอบเขตของ Directory ซึ่ง directory-path จะต้องเขียนตามให้เต็ม Path เช่น
    <Direcotory /var/www>
    ….
    </Directory>

    1.1.2 <DirectoryMatch regexp> … </DirectoryMatch>
    ตั้งค่ากับเฉพาะ ขอบเขตของ Directory ซึ่งสอดคล้องกับ regexp ที่กำหนด เช่น
    <DirecotoryMatch “.*/images/stories/.*”>
    ….
    </DirectoryMatch>

    1.1.3 <Files filename> … </Files>
    ตั้งค่ากับเฉพาะ ชื่อไฟล์ที่ตรงกับ filename ที่กำหนด เช่่น
    <Files “somefile.html”>

    </Files>

    1.1.4 <FilesMatch regexp> … </FilesMatch>
    ตั้งค่ากับเฉพาะ ชื่อไฟล์ที่สอดคล้องกับ regexp ที่กำหนด เช่่น
    <FilesMatch “.*\.php$”>

    </FilesMatch>

    1.2 WebSpace: ได้แก่

    1.2.1 <Location URL-Path> … </Location>
    ตั้งค่ากับเฉพาะ URL ที่ตรงกับ URL-Path เช่น
    <Location /private>

    </Location>
    1.2.2 <LocationMatch regexp> … </LocalMatch>
    ตั้งค่ากับเฉพาะ URL ที่สอดคล้องกับ regexp เช่น
    <LocationMatch “/(extra|special)/data”>

    </LocationMatch>

    2. Other Directive
    ซึ่งมีอยู่มากมาย กรุณาอ่านเพิ่มเติมจาก http://httpd.apache.org/docs/2.2/mod/core.html แต่ในที่นี้ จะขอยกตัวอย่างที่สำคัญ และจำเป็นต้องใช้ ตามตัวอย่างข้างต้น คือ

    Order ordering : อยู่ใน Module mod_access_compat, ค่า ordering ที่สามารถกำหนดได้คือ

    Allow, Deny ซึ่งจะพิจารณาการอนุญาตก่อนปฏิเสธ และ Deny, Allow จะปฏิเสะก่อนแล้วพิจารณาอนุญาต ให้เข้าถึงไฟล์ หรือ ไดเรคทอรี่ต่างๆ

    Deny all|host : อยู่ใน Module mod_access_compat, ค่า all หมายถึง ปฏิเสธทุกการเชื่อมต่อจากทุกๆที่, host สามารถเป็น IP Address หรือ URL ก็ได้

    Allow all|host : อยู่ใน Module mod_access_compat, ค่า all หมายถึง ยอมรับทุกการเชื่อมต่อจากทุกๆที่, host สามารถเป็น IP Address หรือ URL ก็ได้

    ดังนั้น ไฟล์ /etc/apache2/conf.d/jce ซึ่งมีเนื้อหาว่า

    <DirectoryMatch ".*/images/stories/.*>
     <FilesMatch "\.php$">
           Order Deny,Allow
           Deny from All
     </FilesMatch>
    </DirectoryMatch>

    หมายถึง ถ้ามีการเรียก ไฟล์ที่อยู่ใน directory อะไรก็ตามที่มีส่วนหนึ่งของ Path เป็น images/stories ก็จะ ไปดูว่า ชื่อไฟล์ที่เรียกนั้น มีนามสกุลเป็น .php หรือไม่ (.* แปลว่า ตัวอักษรอะไรก็ได้, \. หมายถึงจุด “.” ที่ใช้เชื่อม filename และ extenstion และ $ หมายถึง สิ้นสุดข้อความ) ถ้าเป็นการเรียกไฟล์ .php ใน images/stories ก็จะ ปฏิเสธเสมอ (Deny from ALL)

    แล้ว ทำไมไม่ใช่ .htaccess ?

    จาก Apache Security Tips ไม่แนะนำให้ใช้ .htaccess เพราะปัญหาด้าน Performance เพราะทุกครั้งที่จะเข้าถึงไฟล์ จะต้องพิจารณา .htaccess ทุกครั้ง ในเวปไซต์ที่มีการใช้งานมาก อาจจะทำให้ความเร็วช้าลงได้ อีกประการหนึ่ง .htaccess นั้นอยู่ในไดเรคทอรี่ที่ผู้ใช้สามารถกำหนดสิทธิ์ (Permission) เองได้ หากพลาดกำหนดให้ Web User สามารถเขียนได้ อาจจะทำให้ Hacker เลี่ยงข้อกำหนดต่างๆได้ หาก ที่ Apache Main Configuration ประกาศ AllowOverride เป็น ALL

    ขอให้โชคดี

    Reference

    [1] “Apache HTTP Server Version 2.2 Documentation – Apache HTTP …” 2005. 7 Jan. 2014 <http://httpd.apache.org/docs/2.2/> .

    [2] “Security Tips – Apache HTTP Server.” 2005. 7 Jan. 2014 <http://httpd.apache.org/docs/2.2/misc/security_tips.html>

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

    ตั้งแต่ วิธีตรวจสอบเว็บไซต์ที่โดน Hack #1 เป็นต้นมา เป็นการแสดงให้เห็นถึง ปัญหา, การตรวจสอบ, การค้นหา หลังจากเกิดปัญหาแล้วทั้งสิ้น ก็จะเห็นได้ว่า ยุ่งยาก และเป็นเรื่องยากมาก ที่จะค้นหา Backdoor ให้หมด และการจะกำจัดให้หมดนั้นเป็นภาระอย่างมาก

    ในบทความนี้ จะกล่าวถึง การสำรองข้อมูลไว้ พร้อมๆกับ สามารถตรวจสอบได้ว่า มี Backdoor ใดเกิดขึ้น, มีการแก้ไขไฟล์เพื่อวาง Backdoor ไว้บ้าง, มีการเปลี่ยนแปลงไฟล์ของระบบเป็น Backdoor บ้างหรือไม่ และยังสามารถ กู้ระบบกลับมาได้ แล้วจึงดำเนินการป้องกันไม่ให้เกิดขึ้นซ้ำอีกได้

    การสำรองข้อมูล หรือการ Backup มี 2 แบบ

    1. Full Backup: สำรองทุกไฟล์และไดเรกทอรี่
    2. Incremental Backup: สำรอง “เฉพาะ” ไฟล์และไดเรกทอรี่ ที่มีการเพิ่ม หรือเปลี่ยนแปลง เท่านั้น

    เครื่องมือในการ Backup มีหลายอย่าง ในบทความนี้ ขอใช้ tar เพราะสามารถใช้งานได้ง่าย
    โดยยกตัวอย่าง เป็นการ Backup /var/www/joomla15

    1. Full Backup ทำได้โดยการสร้างไฟล์ fullbackup.sh และมีข้อมูลดังนี้

    d=$(date "+%Y%m%d%H%M%S")
    cp /dev/null joomla15.snar
    tar -zcvf joomla15-full-$d.tar.gz -g joomla15.snar /var/www/joomla15

    2. Incremental Backup ทำได้โดยการสร้างไฟล์ incrementalbackup.sh และมีข้อมูลดังนี้

    d=$(date "+%Y%m%d%H%M%S")
    tar -zcvf joomla15-inc-$d.tar.gz -g joomla15.snar /var/www/joomla15

    โดยคำสั่ง tar มีคำสั่งเพิ่มเติม เล็กน้อย คือ -g ตามตัว joomla15.snar ซึ่ง จะเก็บสถานะของการ Backup ล่าสุดเอาไว้ ทำให้สามารถทราบได้ว่า มีต้อง Backup ไฟล์ใดบ้าง, ส่วน ชื่อไฟล์ .tar.gz ก็จะนำหน้าด้วย วันเวลานาที ของการทำ backup ไว้

    เมื่อทำคำสั่ง

    sh fullbackup.sh

    จะได้ไฟล์นี้

    joomla15-full-20140105004433.tar.gz

    ต่อมา สมมุติ มีการโจมตี Joomla ด้วยช่องโหว่ของ JCE แบบนี้

    jce01

    เมื่อใช้คำสั่ง

    find /var/www/ -name "*.php" -type f | grep 'images/stories'

    ได้ผลดังนี้

    /var/www/joomla15/images/stories/0day.php

    และ สมมุติ Hacker ใช้งาน Backdoor 0day.php ดังกล่าวทาง URL

    http://localhost/joomla15//images/stories/0day.php

    และ แก้ไขไฟล์

    /var/www/joomla15/CREDITS.php

    ดังนี้

    jce02

    สรุปคือ Hacker สามารถ สร้างและเปลี่ยนแปลงไฟล์

    /var/www/joomla15/images/stories/0day.php
    /var/www/joomla15/CREDITS.php

    เมื่อใช้คำสั่ง

    sh incrementalbackup.sh

    จะได้ไฟล์

    joomla15-inc-20140105021906.tar.gz

    วิธีตรวจสอบ ไฟล์ที่เพิ่มเข้ามา และมีการเปลี่ยนแปลง ใช้คำสั่ง diff โดยเอารายการของไฟล็ใน .tar.gz มาเปรียบเทียบกัน ด้วยคำสั่ง

    diff <(tar -ztvf joomla15-full-20140105004433.tar.gz) <(tar -ztvf joomla15-inc-20140105021906.tar.gz) |grep '>'

    ผลที่ได้คือ จะทราบว่ามีไฟล์ ต่อไปนี้ เพิ่ม/เปลี่ยนแปลง

    > -rw-r--r-- www-data/www-data 15571 2014-01-05 02:10 var/www/joomla15/CREDITS.php
    > -rw-r--r-- www-data/www-data 14315 2014-01-05 01:55 var/www/joomla15/images/stories/0day.php

    หาก ต้องการไฟล์ต้นฉบับของ CREDITS.php ก็ใช้คำสั่ง

    tar -zxvf joomla15-full-20140105004433.tar.gz var/www/joomla15/CREDITS.php

    ก็สามารถกู้ไฟล์เดิมกลับมาได้ครับ

    ขอให้โชคดี

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

    ได้รับข้อร้องเรียนจาก Google Webmaster Tools ว่า มีเครื่องภายในมหาวิทยาลัย พยายามโจมตี เครือข่ายภายนอก และทาง Firewall ของมหาวิทยาลัย ได้ทำการปิดกั้น การเข้าออก ของเครื่องดังกล่าวแล้ว จึงเข้าตรวจสอบ

     ขั้นตอนการตรวจสอบ

     1. เบื้องต้น พบว่าเป็น  Ubuntu 8.04.4 LTS

    2. ตรวจสอบ ทำให้ทราบว่า Web User ใดที่สั่งให้ httpd ทำงาน ด้วยคำสั่ง

     ps aux |grep http

     ผลคือ

     nobody   31159  0.0  1.5  29056 15588 ?        S    Dec17   0:00 /opt
    /lampp/bin/httpd -k start -DSSL -DPHP5

     จึงทราบว่า Web User ใช้ชื่อว่า ‘noboby’ (จากที่เคยคุ้นชินกับ www-data, apache อะไรทำนองนั้น)

     3. ตรวจสอบ Process อย่างละเอียดด้วยคำสั่งต่อไปนี้

     ps auxwe

     ผลที่ได้ พบว่า มี Process ของ httpd ทั่วๆไป จะแสดงรายละเอียดอย่างนี้

    nobody     3460  0.0  1.3  28060 14348 ?        S    Dec01   0:00 /op
    t/lampp/bin/httpd -k start -DSSL -DPHP5 LESSOPEN=| /usr/bin/lesspipe 
    %s USER=root MAIL=/var/mail/root SHLVL=4 LD_LIBRARY_PATH=/opt/lampp/li
    b:/opt/lampp/lib:/opt/lampp/lib: HOME=/root LOGNAME=root _=/opt/lampp/
    bin/apachectl TERM=vt100 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin
    :/usr/bin:/sbin:/bin LANG=en_US.UTF-8 LS_COLORS=no=00:fi=00:di=01;34:l
    n=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01
    :su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.t
    gz=01;31:*.svgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31
    :*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.b
    z=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.
    rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*
    .jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;3
    5:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=0
    1;35:*.png=01;35:*.svg=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg
    =01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.
    m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:
    *.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;3
    5:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.aac=00;3
    6:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=0
    0;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36: SHELL=/bin/bash L
    ESSCLOSE=/usr/bin/lesspipe %s %s PWD=/root

    แต่ พบว่า มีอยู่รายการหนึ่ง แสดงผลอย่างนี้

     nobody    5106  0.0  0.2   4168  2184 ?        S    Nov21   1:17 /usr
    /local/apache/bin/httpd -DSSL                                         
    
                                              -m a.txt HOME=/nonexistent O
    LDPWD=/var/spool/cron LOGNAME=nobody PATH=/usr/bin:/bin SHELL=/bin/sh 
    PWD=/home/wwwroot/experience/images/smilies/.laknat/.libs

     จึงตรวจสอบ Process PID 5106 ด้วยคำสั่ง

     ls -la /proc/5106

     ผลที่ได้คือ

     ซึ่ง จะเห็นได้ว่า Process นี้ สั่งทำงานจาก /home/wwwroot/experience/images/smilies/.laknat/.libs/httpd

    แต่ ก่อนหน้านี้ ผู้ดูแลระบบ ได้ สำรองข้อมูลออกไป แล้วลบทิ้งไปก่อนแล้ว จึงขึ้นคำว่า (deleted)

     จาก วิธีตรวจสอบเว็บไซต์ที่โดน Hack #6 พบว่า Hacker มักจะเขียน crontabs เอาไว้ เรียก Backdoor กลับมาอีก จึงทำการตรวจสอบที่ /var/spool/cron/crontabs ด้วยคำสั่ง

     ls -l /var/spool/cron/crontabs/

    ผลที่ได้คือ

    -rw------- 1 nobody crontab 271 2013-11-21 21:45 nobody
    -rw------- 1 root   crontab 256 2011-12-30 09:46 root

     และเมื่อ cat ออกมาดู พบว่า

    cat /var/spool/cron/crontabs/root
    
    # DO NOT EDIT THIS FILE - edit the master and reinstall.
    # (/tmp/crontab.WBj4te/crontab installed on Fri Dec 30 09:46:13 2011)
    # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
    # m h  dom mon dow   command
    0 3 * * * sh /backup.sh
    cat /var/spool/cron/crontabs/nobody
    
    # DO NOT EDIT THIS FILE - edit the master and reinstall.
    # (a.txt.d installed on Thu Nov 21 21:45:40 2013)
    # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
    * * * * * /home/wwwroot/experience/images/smilies/.laknat/.libs/a.txt.upd >/dev/null 2>&1

     แสดงให้เห็นว่า มี crontabs ของ nobody สร้างเมื่อเวลา Thu Nov 21 21:45:40 2013

    4.เครื่องนี้ใช้ lampp เป็น Web Server ซึ่ง ใช้พื้นที่ทำงานคือ

     /opt/lampp

     โดย ให้ผู้ใช้แต่ละคน สร้าง Web ในพื้นที่ /home ของแต่ละคนได้

     และเก็บ Logs ที่

     /opt/lampp/logs

     จึงตรวจสอบด้วยคำสั่ง

     grep "21/Nov/2013:21:45" /opt/lampp/logs/access_log

     ผลที่ได้คือ

    03-logplacefile

    แสดงให้เห็นว่า มีการเรียกไฟล์ *.php ใน images/stories ซึ่ง น่าจะเป็นช่องโหว่ จาก JCE Exploited ตาม วิธีตรวจสอบเว็บไซต์ที่โดน Hack #4 ซึ่งจะใช้วิธีการตามที่อธิบายไว้ก่อนหน้านี้แล้ว เพื่อตรวจสอบต่อไป

    5. เนื่องจาก ผู้ดูแลระบบ ได้สำรองข้อมูลของ /home/wwwroot/experience/images/smilies/.laknat/.libs/ เอาไว้ จึง เรียกออกมาดู

    ได้ผลดังนี้

    จะเห็นได้ว่า ไฟล์ a.txt.upd ถูกสร้างเมื่อเวลา 2013-11-21 21:45 จริงๆ

    เมื่อใช้คำสั่ง

    cat a.txt.upd

     ได้ผลว่า

    a.txt.upd

    จึงลองตรวจสอบ a.txt.run ด้วยคำสั่ง

    cat a.txt.run

     ได้ผลว่า

     a.txt.run

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

    cat a.txt

     ซึ่งเป็นโปรแกรม ภาษา TCL ซึ่งมีรายละเอียดยาวมาก แต่ มีส่วนหนึ่ง เขียนว่า

    a.txt

    และจากการตรวจสอบ ทั้ง directory ก็พบว่า เป็นการเอา Network Tools ต่างๆ ได้แก่ Sniffer, Network Scanner และ อื่นๆอีกมากมาย ซึ่ง เอาตัวโปรแกรม เช่น TCL แบบ Portable มาด้วย หมายความว่า แม้เครื่อง Server ไม่ติดตั้ง TCL ก็สามารถทำงานได้เลยทีเดียว

     ดังนั้น เครื่องนี้ ถูกสั่งงานจากทางไกล กลายเป็น Botnet เพื่อตรวจสอบ เครื่องแม่ข่ายภายใน แม้มหาวิทยาลัยจะมี Firewall ป้องกัน แต่ถูกเครื่องนี้ ดักเก็บข้อมูล และแสดงผลกลับไปให้ Hacker ผ่านทาง Port TCP/80 ซึ่ง Firewall เปิดให้ใช้งานได้เลย

     5. ตรวจสอบว่า มีไฟล์ *.php ใน directory images/stories อีกหรือไม่ ด้วยคำสั่ง

     find /home -name "*.php" -type f | grep 'images/stories'

     ก็พบเพียงไฟล์เดียว คือ

     /home/wwwroot/research_old/images/stories/gh.php

     ซึ่งผิดสังเกต เมื่อตรวจสอบไฟล์ที่สร้างขึ้นในเวลาใกล้เคียงกัน ก็ไม่พบความผิดปรกติ ซึ่ง ไม่ปรกติ

    6. จึงตรวจสอบทั้ง /home ทุกไฟล์ *.php ที่อาจจะมี Backdoor ที่อาจซ่อนการใช้ฟังก์ชั่น eval หรือไม่ ด้วยคำสั่ง

    for f in $(find /home/ -name "*.php" -type f) ; do
      echo $f
      echo "---"
      grep 'eval(' "$f"
      echo "---"
    done

     พบว่า มีไฟล์ *.php ทั้งหมดจำนวน 15,883 ไฟล์ ในนั้นมี 200 กว่าไฟล์ ที่มีการใช้ฟังก์ชั่น eval จริง แต่บางส่วน ก็เป็นไฟล์ที่ถูกต้อง แต่มี 34 ไฟล์ ที่ เป็นไฟล์ Backdoor ใหม่ๆ เพิ่งสร้างขึ้นมา เช่น

    และ เป็นไฟล์ของระบบ ที่มีการแทรก Backdoor Code เข้าไป เช่น

    จึง เก็บรายชื่อไฟล์ทั้ง 34 นี้ ไว้ในไฟล์ ชื่อ 11-manualhack.txt และใช้คำสั่งต่อไปนี้ เพื่อเก็บไฟล์เอาไว้ เพื่อใช้ตรวจสอบต่อไป

     cat 11-manualhack.txt | xargs tar -cvf evalbackdoor.tar

     แล้วจึง ลบทิ้งด้วยคำสั่งต่อไปนี้

     cat 11-manualhack.txt | xargs rm -rf

     7. ตรวจสอบต่อไปว่า มี directory ใดบ้าง ที่ เปิดให้ Web User ‘nobody’ เขียนได้ ด้วยคำสั่ง

     find /home -user nobody -perm -u+w -type d

    พบว่า มี directory จำนวนมากที่เปิดให้ Web User เขียนได้

    และ ใช้คำสั่งต่อไปนี้ ดูว่า มี directory ใดบ้าง เปิดให้ใครๆก็เขียนได้ (World Writable) หรือ ตั้ง permission 777 ด้วยคำสั่ง

    find /home  -perm -o=w -type d

     ก็มีจำนวนมากเช่นกัน

     การแก้ไขปัญหา

    1. เก็บไฟล์ Backdoor ด้วยคำสั่งต่างๆข้างต้น และลบทิ้ง

    2. ปรับให้ทุก Directory เป็น Permission 755 ด้วยคำสั่ง

     find /home -type d -print0 | xargs -0 chmod 0755

     3. ปรับให้ทุก File เป็น Permission 644

     find /home -type f -print0 | xargs -0 chmod 0644

     4. เปลี่ยน Owner และ Group ของทุก Directory และ Files ให้เป็นของแต่ละ User ด้วยคำสั่งประมาณนี้

    chown -R user01.user01 /home/wwwroot

    5. ลบ crontab ด้วยคำสั่ง

    rm /var/spool/cron/crontabs/nobody

    6. หยุด Process PID 5106

    kill -9 5106

     คำแนะนำ

    เนื่องจาก ขณะนี้ได้ เราได้แต่ค้นหา ช่องโหว่ ตามที่เคยเรียนรู้มาเท่านั้น ยังมีรูปแบบต่างๆ ที่ยังไม่รู้อีกมากมาย จึงแนะนำให้

    1. ติดตั้ง OS ใหม่

    2. ติดตั้ง Joomla ใหม่ และ ย้ายเฉพาะ ข้อมูลที่อยู่ใน MySQL มา แล้วจึง Upgrade ให้เป็นรุ่นล่าสุด

    3. ย้ายเฉพาะ ภาพ และ ไฟล์เอกสารสำคัญมา แต่ต้องไม่เอาไฟล์ .php หรือ อื่นๆมาเด็ดขาด

    4. เข้มงวดกับการตั้ง Owner และ Permission กับผู้ใช้งานทุกคนของระบบ, หากจะมี Directory ใดต้องให้มีการ Upload ไฟล์ได้ จะต้องตั้งค่าไม่ให้ PHP ทำงานได้เด็ดขาด

    5. การใช้งาน Joomla จะต้องยกเลิกการ Upload ภาพผ่านทาง HTTP แต่ให้ใช้ FTP แทน

     และ บทความต่อๆไป จะพูดถึงการ Hardening เพื่อลดความเสียหายต่อไป

     ขอให้โชคดี

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

    คราวนี้ เป็นการตรวจสอบ ที่เป็น Windows Server 2008 32bit ที่ใช้ IIS6 เป็น Web Server และใช้ PHP 5.2.17  เครื่องของหน่วยงานภายในมหาวิทยาลัย ซึ่ง ถูก Google Webmaster Tools ตรวจพบว่า เครื่องดังกล่าวน่าจะโดน Hack และมีการวาง Backdoor เอาไว้

    เบื้องต้น พบว่า เครื่องนี้ ใช้ Joomla และรายงานของ Google ก็บอกไฟล์ปัญหา เป็น php ใน images/stories จึง เริ่มจากทำตาม วิธีตรวจสอบเว็บไซต์ที่โดน Hack #3 แต่ ต้องเปลี่ยนไปใช้คำสั่งบน PowerShell แทนที่จะเป็น Shell Script อย่างเดิม

    พื้นที่ Document Root อยู่ที่ c:\inetpub\wwwroot

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

    1. ใช้  powershell ด้วยสิทธิ์ administrator privilege

    2. ค้นหา ไฟล์ *.php ซึ่งอยู่ใน directory “stories” (ใน PowerShell ทำงานแตกต่างจาก Shell Script มากๆ จึงต้องดัดแปลงบางอย่าง)

    gci c:\inetpub\wwwroot -rec -include "*stories*" | where {$_.psiscontainer} | gci -Filter "*.php"

    โดยที่คำสั่งนี้ ใช้ชื่อย่อ และมีความหมายดังนี้

    gci = Get-ChildItem : ทำงานเหมือนคำสั่ง find และใช้ option “-rec” ย่อมาจาก Recurse ซึ่งหมายถึง ค้นหาลงลึกไปใน Subdirectory ด้วย และ เอาเฉพาะใน Directory ย่อย “stories” เท่านั้น

    ส่วนการใช้ ไพพ์ “|” ก็ไม่เหมือนใน Shell Script ที่เป็นการส่ง String หรือข้อความตรงๆ แต่เป็นการส่งต่อ Object

    gci -Filter “*.php” หมายถึง เมื่อค้นหาลึกไปใน Subdirectory “stories” แล้ว ให้กรองเอาเฉพาะไฟล์ แบบ *.php

    ผลที่ได้คือ

    พบว่ามี php file จำนวนมาก ใน images/stories จริงๆ

    ดังภาพ

    3. ตรวจสอบ Log ซึ่งอยู่ที่ c:\inetpub\logs และค้นหาไฟล์ในนั้น ดูว่า มี “BOT.*JCE” บันทึกหรือไม่ ด้วยคำสั่ง

    gci c:\inetpub\logs -rec  | where {$_.psiscontainer} | gci -rec -filter "*.log" | get-content | select-string -pattern "BOT.*JCE"

    ผลที่ได้คือ

    ซึ่งพบว่า มีการโจมตีมาเป็นจำนวนมาก

    4. หา Backdoor อื่นๆ ที่อาจจะเกิดขึ้น หลังจาก Backdoor ใน images/stories เหล่านั้น โดยทดลองดูว่า มีไฟล์ใหม่เกิดขึ้น หลังจากแต่ละ Backdoor นั้นๆ 2 วันหรือไม่ ด้วยคำสั่ง

    $backdoor=gci C:\inetpub\wwwroot\sticorner\images\stories -filter "*.php"
    foreach ($f in $backdoor) {
      $other=gci C:\inetpub\wwwroot\ -rec -filter "*.php" | where-object { $_.LastWriteTime -ge $f.LastWriteTime -and $_.LastWriteTime -le ($f.LastWriteTime).adddays(+2) }  | %{$_.fullname}
     $f.fullname
     $other
    }

    จากการตรวจสอบ พบไฟล์อื่นๆบ้าง แต่ตรวจสอบแล้ว ในระยะเวลา 2 วันหลังจากวางไฟล์ ไม่มีการเขียน Backdoor อื่นๆเพิ่ม

    5. ตรวจสอบหา Backdoor พื้นฐาน ซึ่ง อาจจะใช้ eval แล้วตามด้วย base64_decode ด้วยคำสั่ง

    gci C:\inetpub\wwwroot\ -rec -filter "*.php" | select-string -pattern "eval.*base64" | select-object -unique path >  evalbase64.txt

    โดย เลือกเฉพาะไฟล์ *.php ที่มีคำสั่ง eval ตามด้วย base64_decode มาเก็บไว้ในไฟล์ evalbase64.txt เพื่อใช้ตรวจสอบต่อไป

    พบว่า มีไฟล์จำนวนมาก ที่เป็น Backdoor ดังกล่าว และ Hacker เอาไฟล์มาวางไว้เมื่อ 14/01/2556 แต่ ปลอมวันที่เป็น 15/12/2552 ด้วย ดังภาพ

    และไฟล์ที่พบ มีดังต่อไปนี้

    สำหรับคนที่ดูแล Windows Server ก็ลองใช้เทคนิคข้างต้น ในการค้นหา Backdoor ด้วย PowerShell ด้วย

    ขอให้โชคดีครับ

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

    จากที่ผ่านมา เราได้เรียนรู้จาก

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

    เราได้แต่ตามแก้ไขปัญหา เมื่อเกิดเรื่องขึ้นกับ Website ของเราแล้ว ถึงเวลาแล้ว ที่เราจะต้อง “Proactive” หรือ ทำงานเชิงรุกกันได้แล้ว

    ในโลกเทคโนโลยี มีคนเก่งๆมากมายที่เขาทุ่มเทเวลา เพื่อค้นหาช่องโหว่ต่างๆ ในที่นี้ กรณีของ Joomla ก็สามารถไปดูได้ที่

    Joomla Developer Network  http://developer.joomla.org/security.html

    จากเวปไซต์ดังกล่าว จะเป็นรายงานอย่างเป็นทางการของ Joomla, สิ่งที่ต้องสนใจ คือ

    • Severity: ความร้ายแรง ถ้าเป็นระดับ High, Critical แสดงว่า ร้ายแรง ต้องแก้ไขทันที

    • Versions: รุ่นของ Joomla ที่ได้รับผลกระทบ (ผู้เป็นเจ้าของ ควรรู้ว่าตัวเองใช้รุ่นใด)

    • Exploit type: ลักษณะของช่องโหว่ เช่น XSS, SQL Injection, RFI, Buffer Overflow และอื่นๆ (จะอธิบายในลำดับต่อไป)

    • Reported Date/Fixed Date : แสดง วันที่ที่ตรวจพบ จนถึงวันที่ Joomla ได้แก้ไขปัญหาดังกล่าว

    • CVE Number: แสดงตัวเลขอ้างอิง สำหรับการตรวจสอบกับระบบรักษาความปลอดภัยต่างๆ ถ้ามีตัวเลข CVE แล้ว แสดงว่าปัญหาดังกล่าวมีการยืนยันว่าเป็นปัญหา และมีคนหาทางแก้ไขปัญหาแล้ว รวมถึง มักจะมี Exploited Tools หรือ เครื่องมือในการทดสอบแล้วด้วย ซึ่ง ก็จะมีพวก Script Kiddie หรือ พวกชอบลองของ เอาไปโจมตีเวปไซต์ต่างๆ ทั้งเพื่อความสนุกสนาน และทำลายล้าง (จะอธิบายในลำดับถัดไป)

    • Description และ Solution: รายละเอียดของปัญหา และแนวทางแก้ไข

    CVE ย่อมาจาก Common Vulnerabilities and Exposures ดูรายละเอียดเพิ่มเติมที่ http://cve.mitre.org/ เรียกได้ว่า เป็น ชื่อทางการของช่องโหว่ โดยมีรูปแบบเป็น CVE-YYYY-NNNN โดยที่ YYYY เป็นปี ค.ศ. ที่ค้นพบช่องโหว่ ส่วน NNNN แสดงลำดับในการค้นพบ ดังนั้น จะมีชื่อได้ 10,000 ชื่อ เช่น CVE-2013-5576 แสดงว่า เป็นช่องโหว่ เกิดขึ้นปี 2013 และเป็นลำดับที่ 5576 ของปีนั้น (แต่ ตั้งแต่ 1 ม.ค. 2014 จะมีการเปลี่ยนแปลงรูปแบบ ตัวเลขตั้งแต่ 0-9999 จะยังใช้ NNNN หรือ 4 Digit เหมือนเดิม แต่เมื่อมากกว่านั้น ก็สามารถขยายไปได้เรื่อยๆ เช่น CVE-0001 แต่เมื่อเกิน 10,000 ก็จะเป็น CVE-10001 หรือใช้ NNNNN เป็น 5 Digit นั่นเอง)

    ปัญหาอยู่ที่ว่า จาก Website ของ Joomla Developer Network มักไม่ค่อยให้รายละเอียดมากนัก จึงขอแนะนำ อีก Website คือ

    http://www.scip.ch/en/?vuldb

    เวปไซต์ดังกล่าว จะแสดงรายการช่องโหว่ต่างๆที่ค้นพบ จัดลำดับเวลาในการเกิดเหตุ และความร้ายแรงได้อีกด้วย

    ในกรณีที่ต้องการค้นหา ปัญหาของ Joomla 2.5 สามารถใช้ Google ช่วยค้นหาได้ โดยการค้นหาด้วยคำต่อไปนี้

    joomla 2.5 site:scip.ch

    จากผลการค้นหา จะพบว่า มีหลายช่องโหว่มาก ลองดูสักหนึ่งรายการ

    http://www.scip.ch/en/?vuldb.9847

    จากภาพ แสดงให้เห็นว่า เป็นช่องโหว่ระดับ Critical ของ Joomla รุ่น 2.5.1 / 3.1.4 ซึ่งทำให้ Hacker สามารถ Upload ไฟล์ Backdoor เข้าไปใน Website ได้ และ ช่องโหว่ดังกล่าว ได้ตัวเลข CVE คือ CVE-2013-5576 พบเมื่อ วันที่ 23 ส.ค. 2013

    นอกจากนั้น ยังแสดงรายละเอียดอื่นๆ ได้แก่ CVSS และ OSVDB ซึ่งจะเป็นการแสดงขนาดของผลกระทบ และความยากง่ายในการโจมตี  ซึ่งจะอธิบายต่อไป

    ต่อไป ลองไปดู รายละเอียดของ CVE-2013-5576 ที่
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5576

    จะพบว่า มีคนทำ Exploits ไว้แล้วที่  http://www.exploit-db.com/exploits/27610/

    สำหรับบางช่องโหว่ ก็มีคนไปสร้าง Patch หรือ วิธีแก้ไขให้แล้ว
    จากรุ่น 2.5.13 เป็น 2.5.14 ทำตามนี้
    https://github.com/joomla/joomla-cms/commit/fa5645208eefd70f521cd2e4d53d5378622133d8

    จากรุ่น 3.1.4 เป็น 3.1.5
    https://github.com/joomla/joomla-cms/commit/1ed07e257a2c0794ba19e864f7c5101e7e8c41d2

    CVSS and  OSVDB (เดียวกลับมาเขียนเพิ่มเติม)
    Common Vulnerability Scoring System (CVSS ) เป็นระบบการให้คะแนนช่องโหว่ เพื่อให้สามารถบริหารจัดการ รายละเอียดการคำนวนทั้งหมด ดูได้ที่นี่ http://www.first.org/cvss/cvss-guide.html
    Open Sourced Vulnerability Database (OSDB)

    CWE (Common Weakness Enumeration)

    นอกจากนั้น ยังมีเวปไซต์ ที่เราสามารถดู รายการช่องโหว่ ของ CMS หรือ Software ต่างๆ ได้ที่ CVE Details : http://www.cvedetails.com/

     Joomla มีประวัติช่องโหว่ดังนี้
    http://www.cvedetails.com/vendor/3496/Joomla.html

     Wordpress มีประวัติช่องโหว่ดังนี้
    http://www.cvedetails.com/vendor/2337/Wordpress.html

     

    Mambo ในอดีต และหยุดพัฒนาไปตั้งแต่ปี 2008 มีประวัติช่องโหว่ดังนี้
    http://www.cvedetails.com/vendor/842/Mambo.html

    หวังว่าจะมีประโยชน์ครับ

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

    (ตอนนี้ จะเน้นการตรวจสอบ Joomla เป็นหลักครับ)

    จาก “วิธีตรวจสอบเว็บไซต์ที่โดน Hack #3” ซึ่ง เป็นการตรวจสอบเบื้องต้นว่า มีการบุกรุกผ่านช่องโหว่ต่างๆของ Web Server เข้ามาวาง Backdoor หรือไม่ ซึ่ง ตั้งสมมุติฐานว่า Hacker จะเอาไฟล์ .php มาวางไว้ในไดเรคทอรี่ images/stories เท่านั้น

    แต่ความจริงแล้ว … ไม่ใช่เช่นนั้น

    เพราะ Hacker ต้องคิดต่อไปอีกขั้นหนึ่ง คือ ต้องวางไฟล์ Backdoor ไว้ในที่อื่นๆด้วย รวมถึง พยายามแก้ไขไฟล์ .php ของ Joomla เพื่อไม่ให้ผิดสังเกต และเป็นช่องในการกลับเข้ามาในภายหลัง

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

    ภาพรวมขั้นตอนการปฏิบัติ

    1. ทำการตรวจสอบไฟล์ .php ใน images/stories แล้วเก็บเป็น List เอาไว้
    2. ดึงไฟล์ Backdoor ที่พบ มาเก็บไว้ก่อน ด้วยคำสั่ง tar
    3. ค้นหาไฟล์ ที่เกิดขึ้นหรือถูกแก้ไข ในเวลาใกล้เคียงกันกับ Backdoor นั้นๆ แล้วเก็บเป็น List เอาไว้
    4. ดึงไฟล์ ต้องสงสัย มาเก็บไว้ก่อน แล้ว ตรวจสอบ เป็นรายไฟล์
    5. ลบไฟล์ Backdoor จาก List ในข้อ 1.
    6. ลบไฟล์ ต้องสงสัย หลังจากการตรวจสอบในข้อ 4.
    7. ตรวจสอบ Web User คือใคร
    8. ค้นหา Directory ที่ Web User จากข้อ 7. ที่สามารถเขียนได้
    9. ค้นหา Backdoor พื้นฐานเพิ่มเติม

    รายละเอียดการปฏิบัติ

    คำสั่งต่อไปนี้ อยู่บนพื้นฐานที่ว่า
    Document Root ของ Web Server อยู่ใน /var/www/ ของแต่ละผู้ใช้
    ดังนั้น ขอให้ปรับเปลี่ยนตามระบบของท่าน

    1. ทำการตรวจสอบไฟล์ .php ใน images/stories แล้วเก็บเป็น List เอาไว้
    ใช้คำสั่งต่อไปนี้

    find /var/www/ -name "*.php" -type f | grep 'images/stories' > /tmp/backdoor.txt

    2. ดึงไฟล์ Backdoor ที่พบ มาเก็บไว้ก่อน ด้วยคำสั่ง tar เพื่อให้ในการตรวจสอบ และภายหลัง

    cat /tmp/backdoor.txt | xargs tar -cvf /tmp/backdoor.tar

    ลองตรวจสอบว่า คำสั่งดังกล่าว เก็บไฟล์ได้จริงหรือไม่ ด้วยคำสั่งต่อไปนี้

    tar -tvf /tmp/backdoor.tar

    3. ค้นหาไฟล์ ที่เกิดขึ้นหรือถูกแก้ไข ในเวลาใกล้เคียงกันกับ Backdoor นั้นๆ แล้วเก็บเป็น List เอาไว้ ให้สร้างไฟล์ ชื่อ findbackdoor.sh แล้วใส่เนื้อหาตามนี้

    #!/bin/sh
    BD="/tmp/backdoor.txt"
    TMP01="/tmp/otherbackdoor.txt"
    DMROOT="/var/www/"
    for f in $(cat $BD) ; do
        echo ":: $f ::"
        fdate=$(stat $f |grep ^Modify|awk '{print $2}')
        fdate2=$(date +%Y-%m-%d --date="$fdate 1 day")
        find $DMROOT -type f -name "*.php" -newermt $fdate ! -newermt $fdate2  >> $TMP01
        echo "------"
        echo ""
    done

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

    sh findbackdoor.sh

    โปรแกรมนี้จะทำการค้นหาไฟล์ ที่ถูก “สร้าง/แก้ไข” ในวันที่ backdoor ที่อยู่ใน images/stories ที่พบ และหลังจากนั้น 1 วัน  และ แสดงผลลัพธ์ไว้ในไฟล์ /tmp/otherbackdoor.txt

    4. ดึงไฟล์ ต้องสงสัย มาเก็บไว้ก่อน แล้ว ตรวจสอบ เป็นรายไฟล์

    cat /tmp/otherbackdoor.txt | xargs tar -cvf /tmp/otherbackdoor.tar

    5. ลบไฟล์ Backdoor จาก List ในข้อ 1.
    ซึ่งอยู่ในไฟล์ /tmp/backdoor.txt ด้วยคำสั่ง

    cat /tmp/backdoor.txt | sudo xargs rm -rf

    6. ลบไฟล์ ต้องสงสัย หลังจากการตรวจสอบในข้อ 4.

    คำเตือน ตรวจสอบไฟล์ที่ปรากฏใน /tmp/otherbackdoor.txt ** ทุกไฟล์ ** เพราะ ไม่ใช่ทุกไฟล์ในนี้ จะเป็น Backdoor หากตรวจสอบแล้ว พบว่า ไม่ใช่ ก็ให้ลบบรรทัดนั้น ทิ้งไป ให้ในไฟล์ /tmp/otherbackdoor.txt เหลือแต่ไฟล์ backdoor จริงๆ

    เมื่อมั่นใจแล้ว ลบด้วยคำสั่ง

    cat /tmp/otherbackdoor.txt | sudo xargs rm -rf

    ให้เก็บไฟล์ /tmp/backdoor.tar และ /tmp/otherbackdoor.tar เอาไว้ เพราะในนั้น จะปรากฏ วัน เวลา และรายละเอียดของไฟล์เอาไว้ เพื่อจะใช้ในการ ตรวจสอบหาต้นตอ และช่องโหว่ของระบบต่อไป

    7. ตรวจสอบ Web User คือใคร
    ตั้งสมมุติฐานว่า ท่านใช้ Apache Web Server ซึ่ง จะมีชื่อ Process ว่า httpd หรือไม่ก็ apache (หากใช้ตัวอื่น กรุณาประยุกต์ให้ถูกต้องด้วย) โดยใช้คำสั่ง

    ps aux|egrep -i '(apache|httpd)' > /tmp/webuser.txt

    ผลที่ได้ ให้ดูใน column แรกของไฟล์ /tmp/webuser.txt โดยทั่วไปแล้ว
    CentOS/Fedora/RedHat จะได้เป็น apache
    Linux/Debian จะได้เป็น www-data
    แต่เคยเจอ บางระบบ ให้ user อื่นเป็นคนทำงาน ดังนั้น ให้ตรวจสอบให้เหมาะสมกับระบบตนเองด้วย

    8. ค้นหา Directory ที่ Web User จากข้อ 7. ที่สามารถเขียนได้
    สมมุติ Web User ที่ได้จากข้อ 7. ชื่อ www-data และ Document Root อยู่ที่ /var/www
    ให้ใช้คำสั่งต่อไป เพื่อตรวจสอบว่า มี Directory ใดบ้าง ที่ Web User ดังกล่าวเขียนได้

    find /var/www -user www-data -perm -u+w -type d > /tmp/webuser-dir.txt

    หากพบว่า มี Directory ในไฟล์ /tmp/webuser-dir.txt ให้ ทำการปิด ไม่ให้ Web User นั้นเขียนได้ หรือ เปลี่ยนเป็นของ User อื่นแทน วิธีการนี้ จะทำให้ Hacker ไม่สามารถกลับมาเขียน Backdoor เพิ่มได้อีก

    9. ค้นหา Backdoor พื้นฐานเพิ่มเติม
    ตรวจสอบอีกครั้ง เผื่อจะมี Backdoor อื่นๆซ่อนอยู่ (วิธีการนี้ เป็นเพียง Backdoor ง่ายๆเท่านั้น แต่ดีกว่าไม่ตรวจสอบอะไร)

    find /var/www -name "*.php" -exec egrep -l "eval.*base64_decode" {} \; > /tmp/knownbackdoor.txt
    

     

    หาก Google Web Master Tools ซึ่งทางศูนย์คอมพิวเตอร์ดูแล แจ้งว่า มี Website ใด ภายใต้ Domain psu.ac.th ถูก Hack ทางศูนย์คอมพิวเตอร์ ขอดำเนินการตามนี้

    1. ปิดการเข้าถึงจากภายนอก มายัง TCP Port 80/443 ยัง IP Address ของ Web Server นั้นๆ
    2. แจ้ง ผู้ที่รับผิดชอบ Domain ของ Website ดังกล่าว
    3. ให้ผู้รับผิดชอบ ดำเนินการ ตามขั้นตอนข้อ 1-9 ข้างต้น และ ส่งผลเป็นไฟล์ดังต่อไปนี้มา
      backdoor.txt
      backdoor.tar
      otherbackdoor.txt
      otherbackdoor.tar
      webuser.txt
      webuser-dir.txt
      knowbackdoor.txt
      มาให้ศูนย์คอมพิวเตอร์ ตรวจสอบ
    4. เมื่อตรวจสอบเสร็จแล้ว ทางศูนย์คอมพิวเตอร์ อาจจะขอให้ตรวจสอบด้วยคำสั่งอื่นๆ เพื่อให้แน่ใจว่า ไม่มี Backdoor อันตรายหลงเหลืออยู่
    5. เมื่อมั่นใจแล้ว ทางผู้ดูแลระบบเครือข่าย จะเปิดให้ ภายนอก เข้ามายัง TCP Port 80/443 ยัง IP Address ดังกล่าวได้เหมือนเดิม

    ขอให้โชคดี

    (ใครเอาไปทำแล้ว ได้ผลอย่างไร ขอความกรุณารายงานผลด้วย ขอบคุณครับ)

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

    ต่อจาก “วิธีตรวจสอบเว็บไซต์ที่โดน Hack #1” และ “วิธีตรวจสอบเว็บไซต์ที่โดน Hack #2

    จากการใช้งาน CMS ยอดนิยม อย่าง Joomla อย่างแพร่หลาย ซึ่งเป็นเรื่องง่ายในการพัฒนาเว็บไซต์ เพราะผู้ใช้ สามารถสร้างเนื้อหาได้ง่ายดาย แถมรุ่นใหม่ๆ สร้างแทรกภาพ แทรกวิดีโอได้มากมาย ทำให้เว็บไซต์น่าสนใจ

    แต่สิ่งที่แลกมา คือ ความปลอดภัย เพราะมี Joomla รุ่น 1.5 และใช้เครื่องมือการแก้ไขข้อความ (editor) ที่ชื่อว่า JCE นั้น  (รุ่นต่ำกว่า 2.5) มีช่องโหว่ ซึ่งเรียกรวมๆว่า JCE Exploited

    รายละเอียดของช่องโหว่ สามารถอ่านได้จาก http://www.bugreport.ir/78/exploit.htm

    โดยสรุป วิธีการ Hack ทำเช่นนี้

    1. ตรวจสอบว่า website เป้าหมายมี com_jce หรือไม่
    2. ถ้ามี จะส่งคำสั่ง ผ่านช่องโหว่ทาง URL เข้าไปเพื่อสร้างไฟล์ชื่อ xxxx.gif แล้วเขียนหัวไฟล์ว่า GIF89
    3. จากนั้น ก็ใส่ php code ซึ่งจะใช้เป็น Backdoor เข้าไป
    4. ใช้ช่องโหว่ JCE แก้ไขไฟล์เป็น .php

    เมื่อสามารถเขียนไฟล์ ลงไปได้แล้ว Hacker ก็จะเข้ามาจัดการเครื่องเราในภายหลัง … เช่น เบื้องต้น อาจจะวางไฟล์ 0day.php หรือ อะไรก็แล้วแต่ เพื่อเอาไปอวดเพื่อนๆว่า นี่ๆ ฉัน Hack ได้แล้ว หรือบางคน ก็เข้ามาเปลี่ยนหน้าตาของ Website และเลวร้ายที่สุด คือ สามารถเข้ามาแล้ว เอา Source Code มา Compile บนเครื่องของเรา แล้วยึดเครื่องได้เลย หรืออาจจะเข้ามาใน Network เพื่อ Scan และยิงเครื่องอื่นๆได้เลยทีเดียว

    จาก website ที่อ้างอิงข้างต้น เป็นโค๊ดที่สามารถ นำไปใช้ทดสอบเครื่องในความดูแลของตนเอง แต่ในขณะเดียวกัน ก็จะมี Hacker มือใหม่ หรือที่เรียกว่า Script Kiddie จะลองของ โดยเอา PHP, Perl Script ข้างต้น ไปลอง Hack ดู ซึ่ง … สร้างความเสียหายได้ง่ายๆ

    วิธีการตรวจสอบ ซึ่ง ผู้ดูแล Website พึงตรวจสอบเป็นประจำ

    1. พวก Script Kiddie จะเอาโค๊ดไปใช้ โดยไม่แก้ไขอะไร หรือ แก้ไขเฉพาะให้ Hack ได้ โดยจะลืมแก้ Signature ของ Script ดังภาพ (ส่วนหนึ่งของ Script)

    ดังนั้น จะใน Log File ของ Web Server ก็จะปรากฏข้อความ “BOT for JCE” ด้วย จึงสามารถใช้คำสั่งต่อไปนี้ ค้นหาว่ามีความพยายาม Hack หรือไม่

    grep -i "BOT for JCE" /var/log/httpd/domains/*.log | grep 200

    คำสั่งนี้ จะค้นหาคำว่า  “BOT for JCE” ในที่ที่เก็บ Log File คือ /var/log/httpd/domains/*.log ( ซึ่งแต่ละแห่งใช้ที่เก็บ Log ไม่เหมือนกัน เช่นอาจจะเป็น /var/log/apache2/access.log.* ก็ได้ ขอให้ปรับเปลี่ยนตามความเป็นจริง) และ grep 200 คือ ดูว่า มี Status Code เป็น 200 ซึ่งแปลว่า ติดต่อสำหรับ ดังภาพ

    ถ้าเห็นอย่างนี้บ้าง ก็แสดงว่า เครื่องของเรา มีคนมาเยี่ยมเยียนสำเร็จแล้ว …

    2. ถ้า มีการ Hack สำเร็จ ก็จะวางไฟล์ไว้ โดยพื้นฐาน จะวางไว้ที่ไดเรคทอรี่  images/stories เพราะ Joomla มักจะเปิดให้สามารถ Upload ภาพไปวางได้ เมื่อวางไฟล์ได้แล้ว ก็จะเปลี่ยนนามสกุลจาก .gif เป็น .php  วิธีการค้นหาไฟล์ต้องสงสัย จึงควรหาด้วยคำสั่ง

    find /var/www/ -name "*.php" -type f | grep 'images/stories'

    คำสั่งนี้ จะค้นหาไฟล์ใน /var/www/html ที่มีชื่อเป็น *.php และ ระบุว่า หาเฉพาะชนิดเป็น file (Option -type f) และ เมื่อค้นหาเจอแล้ว ก็จะเลือกเฉพาะที่อยู่ใน ‘images/stories’

    โดยที่ /var/www/html เป็น Web Directory หลัก หรือบางแห่งให้ผู้ใช้ใช้งานได้ใน /home ก็ปรับเปลี่ยนตามความเป็นจริง

    ผลที่ได้ ก็จะเป็นเช่นนี้

    ซึ่งโดยปรกติ ไม่ควรจะมีไฟล์ .php อยู่ใน images/stories ซึ่งเป็นพื้นที่ที่เปิดให้ Upload ไฟล์ภาพเข้ามาได้

    3. หากลองเข้าไปในไฟล์ก็จะพบว่า เป็น Backdoor จริง ตามที่กล่าวไว้ใน “วิธีตรวจสอบเว็บไซต์ที่โดน Hack #2

    ซึ่งจะเห็นได้ว่า ยังมี Back Door ที่สามารถค้นหาในเครื่องด้วยคำสั่ง (ที่เคยบอกไว้แล้ว)

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

    (ก็ขอให้ไปทำกันด้วย …)

    4. แต่ก็จะมีแนวทางใหม่ๆ ซึ่งจะค้นหาด้วยคำสั่งเดิมๆไม่เจอ แบบนี้

    ซึ่ง ทำให้การตรวจสอบเป็นไปได้ยากยิ่งขึ้น … แต่หากใส่ใจกันมากขึ้น ก็จะตรวจสอบความผิดปรกติได้

    5. วิธีตรวจสอบว่า บน Web Server ของเรา มีการใช้ com_jce และ Plugin ที่เสี่ยงต่อการโดน hack หรือไม่ ใช้คำสั่งต่อไปนี้

    find /home/ -name "imgmanager.php" -type f |xargs grep '$version ='

    ผลที่ได้

    Picture1

    แนวทางป้องกัน

    1. หากใช้ Joomla ต้อง Upgrade รุ่นให้ทันสมัยเสนอ และติดตามข่าวสาร และปรับปรุงรุ่นของ Component ต่างๆให้ทันสมัยด้วย

    2. Joomla บนระบบที่ใช้งานจริง (Production) ควรจะเป็น Read Only กล่าวคือ Owner ต้องไม่ใช่ Web User เช่น httpd, apache, www-data เป็นต้น ควรจะเป็นของผู้ใช้แต่ละคน เพราะ หากเกิดการโจมตี จะโดนเป็นรายๆไป ไม่กระทบกระเทือนกัน และระมัดระวัง ผู้ใช้บางคนเปลี่ยนสิทธิ์ Permission เองเป็น 777, 757 อะไรทำนองนั้น

    3. เปลี่ยนวิธี แนวการทำงานใหม่ ห้าม ผู้ใช้แก้ไข Production Site ทาง Web Browser โดยเฉพาะ การ Upload ภาพโดยตรงจาก Web Browser เพราะ ถ้าเปิดให้ Upload ภาพได้ แสดงว่า เปิดให้ Web User สามารถเขียนได้ โดย เปลี่ยนไปใช้วิธี Upload ภาพ ผ่านทาง FTP Client เช่น FileZilla แทน วิธีการนี้ ผู้ใช้ยังสามารถแก้ไข Article ได้ตามปรกติ แต่จะไม่สามารถ Upload ภาพได้โดยตรงเท่านั้น

    4. หากจำเป็นจริงๆ ที่จะต้องเปิดให้ ผู้ใช้ และบุคคลทั่วไป Upload ไฟล์ผ่านทาง Web Browser ได้จริงๆ ก็ต้องใช้ .htaccess เพื่อปิดไม่ให้ php, perl และภาษาอื่นๆ สามารถ Execute Script เหล่านั้น ที่อยู่ในไดเรคทอรี่นั้นๆเด็ดขาด

    5. เครื่อง Production ต้องไม่มี Compiler เพราะจากประสบการณ์ เคยเจอมาแล้ว ที่ Hacker ผ่านมาทางช่องโหว่นี้ แล้ว Upload ไฟล์ .c มาวาง ยังดีที่เครื่องนั้นๆ ไม่มี Compiler

    ขอให้โชคดีครับ

    NOTE FOR Windows Server

    > Find specific file type (*.php) in ‘images/stories’

    gci e:\inetpub\vhosts -rec -include “*stories*” | where {$_.psiscontainer} | gci -Filter “*.php”

    > Find Log files in ‘statistics’ folder with name “*.log” which has “BOT for JCE”

    gci e:\inetpub\vhosts -rec -include “statistics” | where {$_.psiscontainer} | gci -rec -filter “*.log” | get-content | select-string -pattern “BOT for JCE”

    > Find imgmanager.php and the version of file

    gci e:\inetpub\vhosts -rec -filter “imgmanager.php” | get-content | select-string -pattern “version = ”

    > Find some known backdoor

    gci e:\inetpub\vhoss -rec -filter “*.php” | get-content | select-string -pattern “@eval.*base64_decode”