Category: Security

ฉันโดนแฮ๊กหรือเปล่า !?!?!

kanakorn.h

March 5, 2020

หลายท่านอาจจะเคยได้รับ email หน้าตาประมาณนี้

ข้อเท็จจริงคือ

เราสามารถปลอมเป็นใคร ส่ง email ออกไปให้ใครก็ได้
Truth …

แล้ว จะรู้ได้อย่างไร !?!

ต้องดูสิ่งที่เรียกว่า Header … โดยทำตามวิธีการต่อไปนี้

1. คลิกที่ View Full Header

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

จากภาพ จะเห็นว่า ส่งจาก (ดูจาก ล่าง ขึ้น บน)

Received: from [154.117.164.59] (unknown [154.117.164.59])
     by mailscan.in.psu.ac.th (Postfix) with ESMTP id 69F2B150768
     for <kanakorn.h@psu.ac.th>; Thu, 5 Mar 2020 13:24:42 +0700 (ICT)

แล้วจึงส่งเข้าระบบ PSU Email

Received: from mailscan.in.psu.ac.th (unknown [192.168.107.12])
     by mail.psu.ac.th (Postfix) with ESMTP id A034D464FC7
     for <kanakorn.h@psu.ac.th>; Thu, 5 Mar 2020 13:24:46 +0700 (+07)

แล้วจึงเข้า Mailbox ของ PSU (ข้อมูล version ของ cyrus เอาออกไม่ได้จริง ๆ ครับ ไว้รอ Upgrade)

Received: from mail.psu.ac.th ([unix socket])
     by mail (Cyrus v2.4.18-Debian-2.4.18-3) with LMTPA;
     Thu, 05 Mar 2020 13:24:46 +0700

จะเห็นได้ว่า ต้นทางคือ IP Address : 154.117.164.59

ตรวจสอบว่าอยู่ที่ไหนในโลก ด้วย

https://whatismyipaddress.com/ip/154.117.164.59

ประมาณ South Africa

สรุป ! ไม่ได้โดน Hack (ไม่ได้เข้ามาใช้ PSU Email ส่ง)

ครับ

March 5, 2020
ELK #09 Anomaly Detection (Case Study)

kanakorn.h

August 21, 2019
ระบบ PSU Email ให้บริการผู้ใช้ของมหาวิทยาลัยสงขลานครินทร์ ซึ่งมีการใช้งานจากทั่วโลก ทั้งระบบประกอบขึ้นจากคอมพิวเตอร์หลายเครื่อง การจะตรวจสอบ Log เมื่อเกิด Incident ขึ้น อาจจะต้องใช้ระยะเวลานาน และเป็นการยากพอสมควรที่จะเชื่อมโยงความสัมพันธ์ของเหตุการณ์ และสรุปออกมาเป็นรายงานได้ จึงเริ่มใช้ ELK สำหรับรวบรวม Log ของทั้งระบบไว้ที่ส่วนกลาง และพัฒนาต่อยอดเพื่อการตรวจจับความผิดปรกติต่าง ๆ ได้

ในบทความนี้ จะนำเสนอวิธีการใช้ ELK เพื่อตรวจจับ การ Login ที่ผิดปรกติบน PSU Email โดยจะสนใจ ผู้ใช้ที่มีการ Login จากนอกประเทศเป็นหลัก

การส่ง Log จาก Server เข้า ELK

ที่เครื่อง Server แต่ละเครื่อง กำหนดให้ส่ง Log จาก /etc/rsyslog.d/50-default.conf เข้าไปที่ your.logstash.server:port ตามที่กำหนดไว้

การสร้าง Logstash Filter

ที่ Logstash Server
- Input เพื่อรับข้อมูลจาก syslog ที่ port ที่ต้องการ เช่นในที่นี้เป็น 5516 เป็นต้น
- Filter ใช้ Grok Plugin เพื่อจับข้อมูล จาก message แบ่งเป็นส่วน ๆ ตามลักษณะ แล้วตั้งชื่อตาม Field ตามต้องการ ในที่นี้คือ description, username, domainname, clientip, actiondate, actiontime เป็นต้น (ตัวที่สำคัญในตอนนี้คือ username และ clientip)
- Output ตั้งว่าให้ส่งผลไปยัง Elasticsearch ที่ “your.elasticsearch.server” ที่ port 9200
[ตรงนี้มีกระบวนการบางอย่าง ซึ่งค่อยมาลงรายละเอียด]

เมื่อมี Log ไหลเข้าสู่ Logstash และ ถูกประมวลผลแล้ว ก็จะเข้าสู่ Elasticsearch แล้ว ก็นำไปใช้งานบน Kibana

หลังจากนั้น สามารถ Search ข้อมูล และใส่ Fields ที่สนใจ เช่น Time, Username, geoip.country_name และ description ได้ แล้ว Save เอาไว้ใช้งานต่อ ในที่นี้ ตั้งชื่อว่า squirrelmail-geoip

จากนั้น สามารถเอาไปสร้างเป็น Visualization แบบ Coordinate Map ได้ เช่น ดูว่า มีการ Login Success / Failed Login / Sent จากที่ไหนบ้างในโลก

จะเห็นได้ว่า ส่วนใหญ่ ใช้งานจากในประเทศไทย (วงกลมสีแดงเข้ม ๆ) ส่วนนอกประเทศ จะเป็นวงสีเหลืองเล็ก ๆ

การตรวจหาการใช้งานที่ผิดปรกติ

สร้าง Search ใหม่ กรองเฉพาะ ที่มี (exist) Username และ ไม่เป็น N/A และ มี (exist) geoip.country_code และ ไม่ใช่ Thailand แล้ว Save ไว้ใช้งานต่อไป ในที่ตั้งชื่อว่า squirrelmail-geoip-outside-th

จากนั้น เอาไปสร้าง Visualization แบบ Vertical Bar
กำหนดให้
Y Axis เป็นจำนวน
X Axis เป็น Username
โดยที่ Group by geoip.country_name และ description
ก็จะทำให้รู้ว่า ใครบ้างที่ มีการใช้งานนอกประเทศ และ เป็นการใช้งานแบบไหน

จะเห็นได้ว่า จะมีบางคนที่ แสดงสีแค่สีเดียว กับบางคนมีหลายสี เนื่องจาก มีหลายประเทศ และ หลายประเภทการใช้งาน เราสามารถ กรองเอาเฉพาะ ข้อมูลที่สนใจได้ โดยคลิกที่ Inspect แล้วกดเครื่องหมาย + กับข้อมูลที่ต้องการ เช่น description ที่เป็น “Failed webmail login” ก็ได้

ก็จะกรองเฉพาะ Username ที่มีการ Login จากต่างประเทศ แต่ไม่สำเร็จ จากภาพด้านล่าง แสดงว่า 3 คนนี้ น่าจะโดนอะไรเข้าแล้ว

หรือ ถ้าจะกรองข้อมูล เฉพาะคนที่ “Failed webmail login” และ “Message sent via webmail” ก็ได้ แต่ต้องเปลี่ยน ชนิดการ Filter เป็น “is one of”

ผลที่ได้ดังภาพ แต่เนื่องจาก ก็ยังเป็น 3 คนนี้อยู่ จะเห็นได้ว่า คน ๆ เดียว (ซ้ายสุด) มีการ Login จากหลายประเทศ ภายใน 24 ชั่วโมง

ต่อไป ถ้าเราสนใจเฉพาะ คนที่ “ส่งอีเมล” จากนอกประเทศ ในเวลาที่กำหนด จะได้ผลประมาณนี้

พบว่า คนซ้ายสุด คนเดิมนั่นแหล่ะ แต่เราจะมาดูรายละเอียด ก็คลิกที่ปุ่ม Inspect แล้ว เลือก Include เฉพาะ Username นั้น

ก็พบว่า คนนี้มีการส่ง email ออกจากประเทศ USA, Canada, Panama, Argentina, Mexico แล้วบินมา UK ภายในวันเดียว –> ทำได้ไง !!! (ดังภาพด้านล่าง)

เมื่อลองตรวจสอบ ก็จะพบว่า Username นี้ มีพฤติกรรม ส่ง Spam จริง ๆ ก็จะจัดการ “จำกัดความเสียหาย” ต่อไป

วิธีการที่กล่าวมาข้างต้น สามารถสร้างเป็น Process อัตโนมัติ (เว้นแต่ขั้นตอนการ จำกัดความเสียหาย จะ Automatic ก็ได้ แต่ตอนนี้ขอ Manual ก่อน) เอาไว้สำหรับ Monitoring ได้ โดยอาจจะสั่งให้ เฝ้าดู 1 ชั่วโมงล่าสุด และ Refresh ทุก 1 นาที ดังภาพ

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

ส่วนรายละเอียด คอยติดตามตอนต่อไปครับ
August 21, 2019
ปิดช่องโหว่เหลือค้าง

grianggrai.n

August 13, 2019
- หลังจากไม่ได้ตรวจสอบช่องโหว่มานาน วันนี้ Nessus ทำใหม่แล้วลองสแกนซักหน่อย
Nessus Scan Report
- ซึ่งจะพบว่ามี Medium สองรายการ คือ Browsable Web Directory และ WordPress User Enumeration โดย
  - Browsable Web Directory คือ สามารถเข้าถึงรายการใน directory ได้ เช่น ชื่อไฟล์ มีไฟล์อะไรบ้าง ขนาดเท่าไหร่ เป็นต้น เมื่อตรวจสอบก็พบว่าเป็น directory ที่ผู้ใช้ไม่จำเป็นต้องเข้าถึง
  - WordPress User Enumeration คือ สามารถเข้าถึง username ได้ว่ามี user อะไรบ้าง
ปิด Directory Browsing

ทำได้ 2 วิธีคือ
- แก้ไขแฟ้ม config ของ site ที่ต้องการปิด โดยทั่วไปแฟ้มจะอยู่ที่ /etc/apache2/site-enabled/site.conf โดย site.conf คือชื่อไฟล์ที่ต้องการ โดยเพิ่มในส่วนของ Directory ของไซต์นั้น ตัวอย่างเป็น /var/www/html/aaeee ให้ทำการแก้ไขหรือเพิ่มข้อความตามตัวอย่าง ส่วนสำคัญคือ Options ต้องไม่มีคำว่า Indexes เมื่อแก้ไขเสร็จ ให้ reload หรือ restart apache2 ด้วยคำสั่ง sudo systemctl reload apache2 หรือ sudo systemctl restart apache2
```
<Directory /var/www/html/aaeee>
        Options FollowSymLinks
        AllowOverride All
</Directory>
```
- สำหรับวิธีที่สองนี้ ต้องมีการระบุ AllowOverride All ในแฟ้มของไซต์ ด้วยจึงจะใช้งานได้ (หากแก้ไขไฟล์ไซต์ของ apache2 ต้อง reload หรือ restart ด้วย) เช่น
```
<Directory /var/www/html/aaeee>
        AllowOverride All
</Directory>
```
- สร้างแฟ้ม .htaccess เอาไว้ใน Directory (จากตัวอย่างนี้คือ /var/www/html/aaeee) ที่ต้องการ โดยเพิ่มข้อความข้างล่างนี้วิธีนี้ มีผลทันทีไม่ต้อง reload หรือ restart apache2
```
Options -Indexes
```
ปิด WordPress User Enumeration
- ในไซต์ของ WordPress จะมีแฟ้ม .htaccess อยู่ให้เพิ่มข้อความต่อไปนี้ลงไป โดย yoursite.name คือชื่อเว็บไซต์
```
#user enumeration
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* https://yoursite.name/? [L,R=302]
```
- เมื่อทำสองอย่างแล้วให้ nessus เข้าตรวจสอบอีกครั้ง
Nessus Scan Report
- เย่….หายไปละ
- จบขอให้สนุก
August 13, 2019
ติดตั้ง Let’s Encrypt Certificate สำหรับ SSL Sites บน IIS

kampanart.c

January 11, 2019

หลังจากที่พี่หนุ่ม คณกรณ์ หอศิริธรรม ได้เขียนเรื่อง วิธีติดตั้ง HTTPS ด้วย Certificate ของ Let’s Encrypt ไปแล้วนั้น ก็จะมาถึงทางฝั่ง Windows กันบ้าง ซึ่งจะติดตั้งผ่านเครื่องมือ บน Command Line ครับ

ตัวอย่างนี้จะเป็นวิธีการติดตั้งโดยใช้เครื่องมือที่ชื่อว่า WinACME ซึ่ง ดาวน์โหลดได้ที่นี่ (จริงๆ มีหลายตัวให้เลือกใช้ครับ ซึ่งส่วนใหญ่จะเป็นการพัฒนาผ่าน ACME API มีทั้งแบบเป็น Command Line, Power shell และเป็น GUI ครับ)

หลังจากดาวน์โหลดไฟล์มาแล้ว ผม Extract ไปไว้ที่ C:\LetsEncryptSSL

จากนั้นก็เปิด Command Prompt ด้วยสิทธิ Administrator
(เปิดด้วยสิทธิ Administrator เพื่อให้มีการสร้าง Schedule Task ในการ Renew Cert. โดยอัตโนมัติครับ)

จากนั้นทำการเรียกด้วยคำสั่ง letsencrypt จะพบกับเมนูดังภาพนี้ครับ

ผมเลือกตอบตัว “n” จะพบกับเมนูให้เลือกด้านล่างนี้ (สำหรับผู้ที่มีความชำนาญ สามารถเลือก M เพื่อเปิด advanced option ได้ครับ)

และเนื่องจากเครื่องที่แสดงอยู่นี้ เป็น multiple site และผมจะทำการติดตั้งลงไปเพียง 1 site ตามนี้ครับ

เลือก site จากนั้นกด Enter จะพบว่าโปรแกรมเริ่มทำการ Generate SSL Cert. และ Assign ไปยัง Site ของเรา พร้อมทั้งกำหนด Schedule Task เรียบร้อยแล้ว

ลองดูผลลัพธ์ใน II

ลองเปิดเว็บดู ผ่าน Google Chrome ปรากฎว่ามีรูปกุญแจขึ้นแล้วและเป็น Cert. ของ Let’s Encrypt ตามที่ต้องการ

กลับไปตรวจสอบ Schedule Task พบว่ามีการสร้าง Task เพื่อ Renew Cert. เอาไว้แล้ว

จบปิ๊ง…

January 11, 2019
เตือนภัยอีเมลหลอกลวงว่าเป็นธนาคารกรุงไทย (Spam 2018-11-14)

kanakorn.h

November 14, 2018
เช้านี้มีอีเมลหลอกลวงหลุดเข้ามา

อ้างว่ามาจาก Krungthai Bank PCL ดังภาพ

จะเห็นว่า From ก็หลอกว่ามาจาก info@ktb.co.th และในเนื้อหาก็มี Logo ของธนาคาร แถมมี Link ที่วิ่งไป

HTTPS://WWW.KTB.CO.TH/PERSONAL/DETAIL/VERIFY/172

แต่ไม่ใช่ของจริง !!!

เพราะ ถ้าท่านดูอีเมลฉบับนี้แบบ HTML จะเป็นการส่ง Link ไปที่ “เว็บไซต์หลอกลวง” หรือเรียกว่า Phishing Site

ไม่แนะนำให้คลิกตาม

https://scrappse.tk/jssl/ktbnetbank/krungthai/index.html

ซึ่งจะได้หน้าตาเหมือนกับของธนาคารจริง ๆ เพราะมันไปใช้ภาพจากเว็บไซต์จริง

เว็บไซต์หลอกลวง !!!!

และใช้ HTTPS และได้ “กุญแจ” ที่บอกว่า valid certificate อีกด้วย เพราะใช้ Let’s Encrypt

ดังนั้นจึงแจ้งเตือนภัยมายังประชาคมให้รับทราบ ว่าปัจจุบันนี้
- เห็น LINK ใน Email แล้วเป็น URL ชื่อของธนาคารจริง ก็ยังไม่พอ (กรณีนี้เป็นของ www.ktb.co.th)
- คลิกไป เจอหน้าเว็บ หน้าตาน่าเชื่อถือ ก็ไม่พอ (ตามภาพ เลียนแบบเหมือนมาก)
- ดูว่ามี “กุญแจ” ของ HTTPS ถูกต้องก็ไม่พอ (กรณีนี้ ได้กุญแจมาแล้ว แต่เป็นของเว็บไซต์หลอกลวง)
- ดังนั้น ต้องดูด้วยว่า URL ที่ท่านเห็นด้านบน เป็นของธนาคารจริง ๆ หรือไม่ !!! (ในกรณีนี้ ไม่จริง เพราะเป็นของ https://scrappse.tk )
ธนาคารกรุงไทย ได้แจ้งเตือนเรื่องนี้ไว้แล้วที่

https://www.ktb.co.th/th/krungthai-update/announcement-detail/162

ดังนั้น หากท่านได้รับ Email ในทำนองนี้ ให้ตรวจสอบกับธนาคาร หรือผู้เชี่ยวชาญก่อน เพราะคนร้ายจะหลอกให้ท่านกรอก Username/Password เพื่อเข้าสู่บัญชีธนาคารของท่านได้
November 14, 2018
วิธีตั้งค่า HTTPS บน Apache2 รุ่นที่สูงกว่า 2.4.8

kanakorn.h

October 12, 2018
จากบทความ การแก้ไข Certificate สำหรับ Apache Web Server (Ubuntu 14.04 LTS) ตอนนี้ Apache2 รุ่นที่สูงกว่า 2.4.8 ประกาศให้ SSLCertificateChainFile นั้น obsolete หรือ จะไม่ใช้อีกต่อไป

จากเดิม เราเคยใช้
```
SSLCertificateFile /etc/apache2/cer/[cer-file-name].crt
SSLCertificateKeyFile /etc/apache2/cer/[cer-file-name].key
SSLCertificateChainFile /etc/apache2/cer/[cer-file-name].ca-bundle
```
ต่อไปนี้ แนะนำให้ใช้แค่
```
SSLCertificateFile /etc/apache2/cer/[cer-file-name]_combined.crt
SSLCertificateKeyFile /etc/apache2/cer/[cer-file-name].key
```
แล้ว
```
/etc/apache2/cer/[cer-file-name]_combined.crt
```
มาจากไหน ??? มันมากจากการเอาไฟล์ [cer-file-name].crt แล้วต่อท้ายด้วยไฟล์ [cer-file-name].ca-bundle ด้วยคำสั่ง
```
cat [cer-file-name].crt [cer-file-name].ca-bundle > [cer-file-name]_combined.crt
```
เช่น
```
cat in_psu.crt intermediate_ca.crt > in_psu_combined.crt
```
เป็นต้น เสร็จแล้ว ก็ Restart Apache — จบแค่นี้ ใช้งานได้

TL;DR

Q: มีไฟล์ .crt เต็มไปหมด จะรู้ได้ไงว่า อันไหนคือ Certificate ของอะไร อย่างไร

A: สมมุติ Certificate ของ Server ที่ได้มา ชื่อ server.crt ต้องใช้คำสั่งนี้ ดูรายละเอียด
```
openssl x509 -in server.crt -text
```
ผลที่ได้ จะประมาณนี้

สิ่งสำคัญที่ควรดู ในที่นี้คือ Issuer จะเห็นว่า CN หรือ common name คือ AlphaSSL CA – SHA256 – G2 และบรรทัด Subject จะบอกว่า Domain (*.xxxxx.psu.ac.th) ที่ลงทะเบียนไว้ อยู่ภายใต้ “AlphaSSL CA” อีกที

ซึ่ง ถ้าไปดูใน /etc/ssl/certs ก็จะเห็นว่า ไม่มี CA Certificate ของ “AlphaSSL CA” นี้อยู่ แต่จะมีของ “GlobalSign Root CA” อยู่

ทำไมเป็นอย่างนั้น ??? เพราะ CA เค้าต้องรักษา Root Certificate ของตนเองไว้ให้ดี จึงออกสิ่งที่เรียกว่า Intermediate CA ขึ้นมาอีกชั้นหนึ่ง แล้วแจกจ่ายให้กับผู้ที่ซื้อ Certificate ของเค้าอีกชั้นหนึ่ง

คราวนี้ มาลองดูข้อมูลใน intermediate_ca.crt ว่ามีข้อมูลเป็นอย่างไร ด้วยคำสั่ง
```
openssl x509 -in intermediate_ca.crt -text
```
จะเห็นได้ว่า Issuer เป็น “GlobalSign Root CA” และ Subject เป็น “AlphaSSL CA”

จากเดิม Apache2 รุ่น < 2.4.8 ให้ใช้ Directive “SSLCertificateChainFile” ในการกำหนด Intermediate CA ได้ แต่หลังจากนั้น ก็ให้ Obsolete เพราะ สามารถเอา 2 ไฟล์มาต่อกันได้ตามที่เขียนไว้ข้างต้น

ในทางปฏิบัติ จริง ๆ แล้ว ก็ยังใช้ได้อยู่ แต่เป็น Obsolete ทางที่ดี ก็ควรจะปรับปรุงตามที่แนะนำไว้จะดีกว่า

และ ถ้าใช้งานแค่ SSLCertificateFile (แบบที่มีแต่ Server Certificate) และ SSLCertificateKey (Server Private Key) นั้น เมื่อ Restart apache2 แล้ว ทดสอบใช้งานกับ Web Browser ส่วนใหญ่ จะใช้งานได้ ไม่ต้องอ้าง Intermediate CA ก็ได้ *** เพราะใน Web Browser ได้ติดตั้ง Intermediate CA พวกนี้ไว้เป็นส่วนใหญ่แล้ *** แต่ถ้าลองเรียกผ่าน curl หรือบริการอื่น ๆ เช่น จาก Google DialogFlow Fulfillment ก็จะเรียกไม่ผ่าน เพราะในระบบเค้าไม่ได้ใส่ Intermediate CA ไว้นั่นเอง

การที่ Combined ทั้ง Server Certificate และ Intermediate CA ไว้ในไฟล์เดียวกัน ทำให้มั่นใจได้ว่า สามารถใช้งาน https ได้จากทุก Platform นั่นเอง

หวังว่าจะเป็นประโยชน์ครับ
October 12, 2018
Hardening your HTTP response headers

grianggrai.n

September 12, 2018
Introduction

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

Header ของ Apache2 ที่ควรต้องใส่เพื่อเพิ่มความปลอดภัยมีดังนี้

Content Security Policy

Header เรื่อง Content Security Policy (CSP) ช่วยให้กำหนดต้นทางของเนื้อหาที่อนุญาตสำหรับเว็บไซต์ โดยการจำกัดเนื้อหาที่เบราเซอร์สามารถโหลดได้ ได้แก่ js และ css

สามารถสร้าง CSP ได้จาก https://report-uri.com/home/generate ทั้งนี้ต้องทดสอบการทำงานทุกครั้งเนื่องจาก การกำหนดค่าบางอย่างอาจทำให้เว็บไซต์ ทำงานไม่ถูกต้อง ดูรายละเอียดเพิ่มเติมได้ที่ https://scotthelme.co.uk/content-security-policy-an-introduction/ สำหรับ Apache2 เพิ่ม Header ต่อไปนี้ ในแฟ้มของไซต์ที่ต้องการ เช่น /etc/apache2/site-enabled/lsc-ssl.conf หรือแฟ้ม .htaccess ในไซต์ที่ต้องการ (ซึ่งแนะนำว่าใช้ .htaccess จะได้ไม่ต้องรีสตาร์ทเซิร์ฟเวอร์) เพื่อเปิดการใช้งาน CSP
```
Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"
```
HTTP Strict Transport Security (HSTS)

เว็บไซต์ ต้องมีการตั้งค่าให้ redirect จาก HTTP ไปยัง HTTPS เสมอ และ HSTS จะเป็น Header ที่กำหนดให้เบราเซอร์จำสถานะของ HTTPS เอาไว้แม้ว่าจะเป็นการเปิดจาก bookmark ที่เป็น HTTP ก็ตาม ก็จะถูกบังคับให้เป็น HTTPS รายละเอียดเพิ่มเติม https://scotthelme.co.uk/hsts-the-missing-link-in-tls/ เช่น เมื่อเปิด http://licensing.psu.ac.th ก็จะถูก redirect ไป https://licensing.psu.ac.th
```
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
```
X-Frame-Options

X-Frame-Options หรือ XFO header จะช่วยป้องกันผู้ใช้จากการโจมตีแบบ clickjacking ที่ผู้บุกรุกสามารถโหลด iframe จากไซต์ของเขาบนไซต์ของเราได้ ซึ่งทำให้ผู้ใช้งานเว็บไซต์ของเราเชื่อว่าไม่อันตราย!! รายละเอียดเพิ่มเติม https://www.troyhunt.com/clickjack-attack-hidden-threat-right-in/
```
Header always set X-Frame-Options "SAMEORIGIN"
```
X-Xss-Protection

Header นี้ใช้กำหนดค่าการป้องกัน XSS ที่มีอยู่บนเบราเซอร์ต่างๆ โดยการตั้งค่าจะมี 0 คือ ปิดการทำงาน 1 คือเปิดการทำงาน และ 1; mode=block ซึ่งจะกำหนดให้เบราเซอร์ทำการบล็อคการกระทำใดๆ ก็ตามที่มากกว่าการล้างข้อมูลสคริปต์
```
Header always set X-Xss-Protection "1; mode=block"
```
X-Content-Type-Options

X-Content-Type-Options ใช้ในการป้องกันการโจมตีผ่านทางช่องโหว่ MIME sniffing ซึ่งจะเกิดเมื่อ เว็บไซต์อนุญาตให้ผู้ใช้อัพโหลดเนื้อหาไปยังเซิร์ฟเวอร์ ซึ่งผู้ใช้อาจเปลี่ยนหรือซ่อนไฟล์อันตราย แล้วอัพโหลดขึ้นเซิร์ฟเวอร์ รายละเอียดเพิ่มเติม https://www.keycdn.com/support/x-content-type-options/
```
Header always set X-Content-Type-Options "nosniff"
```
เบื้องต้นแนะนำเท่านี้ก่อนครับ พิเศษ!! สำหรับผู้ใช้งาน wordpress มีปลั๊กอินชื่อ HTTP Headers ใช่ตั้งค่า Header ต่างๆ ที่เล่ามาข้างต้นได้อย่างสบายใจหายห่วง!!! ไม่ต้องแก้ .htaccess ไม่ต้องแก้ config ใด ๆ เมื่อติดตั้งเสร็จแล้วจะพบว่ามี Header อีกมากที่สามารถตั้งค่าเพิ่มเติมได้ ซึ่งจะกล่าวอีกในครั้งต่อ ๆ ไป

ต้นฉบับ

https://scotthelme.co.uk/hardening-your-http-response-headers/
มีวิธีการเซ็ตสำหรับ Nginx และ IIS สามารถดูเพิ่มเติมได้ครับ

อย่าลืม!!

ตรวจ HTTP Response ได้ที่ https://securityheaders.com

จบขอให้สนุก
September 12, 2018

อย่าเชื่อเครื่องมือมากเกินไป …

kanakorn.h

August 27, 2018

เมื่อเดือนมีนาคม 2561 ผมได้ทำการทดสอบเครื่องมือเจาะระบบ “N” (ใช้ทดสอบว่าระบบเป้าหมายมีช่องโหว่ใดให้โจมตีบ้าง) ภายใต้ภาระกิจ “Honeypot” เพื่อทดสอบว่า เครื่องมือดังกล่าว สามารถรับรองความปลอดภัยของระบบปฏิบัติการของเครื่องเซิร์ฟเวอร์ ก่อนที่จะอนุญาตให้เข้าถึงได้จากอินเตอร์เน็ตได้หรือไม่

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

วิธีการทดสอบ

จัดให้มีเครื่องทดสอบ ชื่อ honeypot.in.psu.ac.th อยู่บน VM และใช้เครื่องมือเจาะระบบ “N” ตรวจสอบ 2 ครั้ง โดยครั้งแรก (Baseline 01) เป็นการติดตั้งระบบปฏิบัติการ Ubuntu 16.04 LTS แบบ Default และ Update ให้เป็นปัจจุบันที่สุด แล้วรีบแจ้งให้ “N” ตรวจสอบ ครั้งที่ 2 (Baseline 02) ทำการติดตั้ง Web Server, PHP, MySQL และติดตั้งช่องโหว่อย่างง่ายที่พัฒนาขึ้นเอง (https://github.com/nagarindkx/honeypot) ลงไป โดยภาพรวมดังภาพที่ 1 แล้วรีบแจ้งให้ “N” ตรวจสอบ

honeypot.in.psu.ac.th ประกอบด้วยโครงสร้างไฟล์ ดังภาพที่ 2

เมื่อคลิก Login with SQL Injection Vulnerable จะได้ภาพที่ 3 ซึ่งจะส่งไปที่ไฟล์ badform.html โดยในฟอร์มนี้จะมีช่องโหว่ SQL Injection ทำให้สามารถเข้าเป็น admin ได้โดยลองใส่ username/password ดังนี้

**ภาพที่ 3:** http://honeypot.in.psu.ac.th/badform.html

ซึ่งจะได้ผลว่า สามารถเข้าเป็น admin ได้โดยไม่ต้องทราบรหัสผ่านที่แท้จริง แต่อาศัยการเขียน SQL Statement ที่ไม่รัดกุม และไม่ตรวจสอบ Input ก่อน ดังภาพที่ 4

เมื่อคลิก Simple Non Persistent XSS จะได้ภาพที่ 5 ซึ่งจะส่งไปยัง simple.php โดยจะเห็นได้ว่า สามารถใส่ชื่อ นามสกุล ลงไปใน URL ได้เลย ผ่านตัวแปร name (ต้องลองใช้กับ FireFox ถ้าเป็น Google Chrome จะมี XSS Auditor ไม่ได้รับผลกระทบ)

**ภาพที่ 5:** ช่องโหว่ Non Persistent XSS

ช่องโหว่นี้ ทำให้ Hacker นำเว็บไซต์นี้ไป ดักเอา Cookie Session ของผู้อื่น หรือ Session HiJacking ดังภาพที่ 6
ด้วย URL นี้
http://honeypot.in.psu.ac.th/simple.php?name=%3Cscript%3Ealert(escape(document.cookie))%3C/script%3E

หรือ เปลี่ยนเปลี่ยน URL ที่ “Click to Download” ไห้ยังเว็บไซต์ที่ต้องการได้ เช่นเป็น hacked.com เป็นต้น ดังภาพที่ 7 ด้วย URL นี้
http://honeypot.in.psu.ac.th/simple.php?name=%3Cscript%3Ewindow.onload=function()%20{%20var%20link=document.getElementsByTagName(%22a%22);%20link[0].href=%27http://hacked.com%27}%3C/script%3E

เมื่อคลิก Login to Test Permanent XSS จะได้ภาพที่ 8 ซึ่งจะส่งไปยัง goodlogin.php

ซึ่ง เป็น Form ที่ป้องกัน SQL Injection และ ไม่ยอมรับ username/password ว่าง หากไม่ทราบรหัสผ่านจริงๆ ก็จะเข้าไม่ได้ ดังภาพที่ 9

หาก Login เป็น user1 สำเร็จ จะสามารถเปลี่ยน Display Name ได้ ดังภาพที่ 10
ทดลองด้วย

username: user1
password: user1123**

**ภาพที่ 10**: user1 เมื่อ Login สำเร็จ สามารถเปลี่ยน Display Name ได้

หาก user1 ต้องการดัก Session HiJack จาก Admin สามารถทำได้โดย แก้ Display Name ดังนี้

เมื่อกดปุ่ม Update จะได้ภาพที่ 11

**ภาพที่ 11**: user1 วาง Session HiJacking สำเร็จ

เมื่อ admin เข้ามาในระบบ ด้วย

username: admin
password: admin123**

จะได้ภาพที่ 12

**ภาพที่ 12**: admin จะมองเห็นรายชื่อ users ทั้งหมด ในที่จะเห็น user1 ที่มี display name ของตนเองเป็น Link

เมื่อ admin ติดกับดัก ลองคลิก link ที่เขียนโดย user1 ก็จะเปิดเผย (และสามารถส่ง session กลับไปให้ user1 ได้หลายวิธี) ก็จะได้ผลดังภาพที่ 13

**ภาพที่ 13**: แสดง Session ของ Admin ซึ่งในช่วงเวลานั้นๆ user1 สามารถเข้ามาเป็น admin ได้โดยไม่ต้องทราบรหัสผ่านของ admin

*** และ มี Backdoor ที่อยู่ใน /uploads/ ไฟล์ image.php ที่ ไม่ได้แสดงใน index.php หน้าแรก ซึ่งจะสามารถส่งคำสั่งเข้าไปให้ Execute ได้ เช่น ls -l ดังภาพที่ 14 หรือ แม้แต่ wget ไฟล์จากภายนอกมาไว้ในนี้ได้ เพื่อสร้าง Backdoor ในที่ต่างๆ ซึ่งเรียกว่า Remote Code Execution

**ภาพที่ 14**: Backdoor ใน /uploads/image.php ที่ไม่ได้อยู่ใน index.php หน้าแรกของ honeypot

ผลการทดสอบ

จากผลการทดสอบด้วย “N” เมื่อ Mon, 12 Mar 2018 13:57:16 ICT ผลดังภาพที่ 15

**ภาพที่ 15:** แสดงรายการช่องโหว่ “N” ตรวจพบ ประกอบด้วย 1 High, 5 Medium Risk

ผลการทดสอบสามารถสรุปเป็นตารางได้ ดังตารางที่ 1

ตารางที่ 1: แสดงผลเปรียบเทียบสิ่งที่ honeypot วางไว้ กับสิ่งที่ “N” ตรวจพบ ตามตำแหน่งไฟล์ต่างๆ

ตำแหน่งไฟล์	Honeypot วาง	“N” ตรวจพบ
badform.html	SQL Injection	ยอมรับได้ – Web Application Potentially Vulnerable to Clickjacking (เป็น Form ที่ยอมให้เว็บอื่นเอาไปใส่ใน iframe ได้)
login.php	JavaScript Injection	เป็น False Positive เพราะ Login Fail – CGI Generic SQL Injection (blind) – CGI Generic XSS (quick test) – CGI Generic Cookie Injection Scripting – CGI Generic XSS (comprehensive test) – CGI Generic HTML Injections (quick test) ยอมรับได้ – Web Application Potentially Vulnerable to Clickjacking (เป็น Form ที่ยอมให้เว็บอื่นเอาไปใส่ใน iframe ได้) ไม่เข้าไปตรวจ JavaScript Injection เพราะไม่ได้ตรวจสอบ SQL Injection จากหน้า badform.html
simple.php	Non-Persistent XSS	ยอมรับได้ – CGI Generic XSS (quick test) – CGI Generic Cookie Injection Scripting – CGI Generic XSS (comprehensive test) – CGI Generic HTML Injections (quick test)
goodlogin.php	–	เป็น False Positive เพราะ Login Fail – CGI Generic SQL Injection (blind) ยอมรับได้ – Web Application Potentially Vulnerable to Clickjacking (เป็น Form ที่ยอมให้เว็บอื่นเอาไปใส่ใน iframe ได้)
home.php	Persistent XSS	ไม่เข้าไปตรวจ เพราะไม่สามารถเดารหัสผ่านที่ถูกต้องได้
/uploads/image.php	Backdoor (Remote Code Execution)	ไม่เข้าไปตรวจ เพราะไม่มี Link จากหน้าแรก

สรุปผลการทดสอบ

น่าตกใจ ที่ “N” ไม่สามารถตรวจพบ SQL Injection ได้ในหน้า badform.html
“N” ตรวจพบ XSS ในหลายรูปแบบในหน้า simple.php ซึ่งนับว่าดี
“N” ตรวจสอบได้เฉพาะ URL ที่สามารถติดตามไปจากหน้าแรกได้เท่านั้น จะเห็นได้ว่า ไม่สาามารถเข้าไปตรวจสอบ home.php ซึ่งต้องเดารหัสผ่านให้ได้ก่อน และ /uploads/image.php ซึ่งไม่มีการเรียกจากหน้าแรก ซึ่งโดยทางปฏิบัติ Hacker เมื่อเจาะเข้ามาวางไฟล์ได้แล้ว จะเอา URL นั้นไปโพสต์ประกาศในกลุ่ม หรือ บนหน้าเว็บไซต์อื่นๆ เช่น zone-h.org เป็นต้น ทำให้ เราตรวจด้วย “N” ยังไงก็ไม่เจอ แต่ Google ตรวจเจอเพราะไปตรวจสอบเว็บไซต์ของกลุ่ม Hacker อีกที
“N” ทำงานเป็นลำดับ ดังนั้น เมื่อ ไม่ตรวจพบ SQL Injection ในหน้า badform.html ก็ไม่ตรวจ JavaScript Injection ในหน้า login.php
“N” เตือนเรื่องสามารถนำ Form ไปอยู่ใน iframe ของเว็บไซต์อื่นๆได้ ซึ่งนับว่าดี

อภิปรายผลการทดสอบ

การมีเครื่องมือในการเจาะระบบอย่าง “N” เป็นเรื่องดี ทำให้สามารถลดงานของผู้ดูแลระบบได้ อย่างน้อยก็เรื่องการตรวจสอบ Version ของ OS, Software ที่ใช้ ว่าได้รับผลกระทบต่อช่องโหว่ที่สำคัญ ซึ่งจะประกาศเป็นเลข CVE เอาไว้แล้ว ทำให้ตรวจสอบภาพรวมๆได้ และตรวจสอบได้ตาม Signature ที่บริษัทเค้ากำหนดมาเท่านั้น

อย่างไรก็ตาม ในทางปฏบัติ “N” หรือ เครื่องมืออื่นๆที่ทำงานแบบ Outside-In อย่างนี้ จะไม่มีทางตรวจสอบ ช่องโหว่ ที่อยู่ “ภายใน” เครื่องได้ หากแต่ การตรวจสอบ Log File และ การตรวจสอบเครื่องเซิร์ฟเวอร์จากภายใน จึงเป็นสิ่งจำเป็นอย่างยิ่ง นอกจากจะทำให้เราตรวจพบช่องโหว่ต่างๆก่อนจะโดนรายงาน แล้ว ยังเป็น การสะสมความรู้ซึ่งสำคัญยิ่่งกว่า เพราะเราจะได้ทำการ ป้องกัน ก่อนที่จะต้องมาตามแก้ไข อย่างเช่นในปัจจุบัน

August 27, 2018

วิธีเอา Boxbe ออกไปจากชีวิตของคุณ

kanakorn.h

August 2, 2018
Boxbe เป็น Free Service ที่พยายามจะจัดการกับ Spam โดยอยู่บนสมมุติฐานว่า ผู้ที่ไม่อยู่ใน Contact ของเรา หรือ อยู่ใน Guest List นั้น มีแนวโน้มจะเป็น Spam เมื่อมีการส่ง email จากกลุ่มนี้ ก็จะถูกเอาไปอยู่ในกล่องที่เป็น Wait List จึงทำให้กล่อง Inbox ซึ่งเราจะอ่าน email เป็นประจำนั้น มาจากคนที่อยู่ใน Contact เท่านั้น

โดยความตั้งใจ ดูดี แต่ …

คนใน Contact ของเรา เป็น Subset ของ email universe ที่เราจะต้องติดต่อด้วย สำหรับคนที่ไม่ได้ทำธุรกิจติดต่อกับคนที่ไม่เคยรู้จักมาก่อน หรือติดต่อเฉพาะคนในองค์กร ก็พอจะไปได้ แต่ในความเป็นจริง ไม่ใช่ทุกคนที่ต้องการอย่างนั้น

อีกปัญหาหนึ่งคือ ก่อนหน้านี้ เมื่อมีคนที่ไม่ได้อยู่ใน Contact ของเราติดต่อมา สิ่งที่ Boxbe ทำคือ ส่ง email ตอบกลับไปยังผู้ส่ง ว่า “email ของคุณถูกส่งไปอยู่ใน Wait List” แล้วก็อธิบายด้วยข้อความที่ค่อนข้างสับสน

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

เมื่อคลิก สิ่งที่เกิดขึ้นคือ Boxbe จะพาไปยังหน้า Sign-Up Boxbe (จริง ๆ แล้ว ปุ่มสีน้ำเงิน นั่นก็บอกแล้วว่า เป็นการ Sign-Up) แล้วก็ของ Permission ในการ “Read, send, delete and manage your email”

และแน่นอน ผู้ใช้ก็กด Allow เป็นธรรมดา หลังจากนั้น …. คุณก็เป็นสมาชิกของ Boxbe ไปโดยไม่รู้ตัว และเกิดปฏิกิริยาลูกโซ่ตามมา คือ คนที่ส่ง email ถึงคุณก็จะได้รับข้อความตอบกลับจาก Boxbe และ คนเหล่านั้นก็ทำอาการเดียวกับคุณ 5555 เข้าใจตรงกันนะ

เอาเป็นว่า มาดูวิธีเอา Boxbe ออกจากชีวิตดีกว่า
1. อันดับแรก ให้ไป Delete Boxbe Account ก่อน โดยไปที่ https://www.boxbe.com/ แล้วคลิกที่ Sign In หรือ ถ้า Login ค้างอยู่ให้คลิกที่ Dashboard
2. จากนั้น คลิก Disable Account
3. แล้วพิมพ์คำว่า Yes แล้วคลิกปุ่ม Close Forever
ยัง …. ไม่ยังไม่ตาย เพราะตอนที่ Sign Up นั้น เราไปอนุญาตให้ Boxbe เชื่อมต่อกับ Account ของเรา ในตัวอย่างนี้ เป็นกรณีของ Gmail
1. ไปที่ https://myaccount.google.com/permissions เราจะเจอ Boxbe นั่งยิ้มหวานอยู่
2. บรรจงคลิก Boxbe แล้วคลิก Revoke Access
3. แล้วก็คลิก OK
จบจ้า
August 2, 2018