Security – Page 14 – CoP PSU IT Blog

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

July 2, 2014 11:18

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

May 1, 2014 22:11

บทความนี้ เสนอเรื่อง 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 ของเว็บไซต์ต่างๆ

วิธีจัดการ Facebook Spam

March 28, 2014 10:51

เมื่อ 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

March 13, 2014 11:03

ใช้ได้กับ 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

January 22, 2014 01:20

บทความนี้ แสดงให้เห็นการโจมตีช่องโหว่ของ 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