คลังเก็บป้ายกำกับ: DATABASE_SECURITY

Oracle แพตซ์อุดช่องโหว่ Micros PoS ที่ใช้กับระบบชำระเงินด้วย เครดิต/เดบิต กว่า 3 แสนแห่ง

Oracle ได้ออกแพตซ์แก้ไขปัญหา Bug ที่ทำให้เกิดช่องโหว่บนระบบ PoS (Micros point-of-sale) ที่แฮ็กเกอร์สามารถนำไปใช้เพื่อเก็บไฟล์การตั้งค่าของระบบ Micros PoS รวมถึงการได้รับสิทธิ์เต็มที่และเข้าถึงระบบ PoS อย่างถูกต้องและบริการอื่นที่ติดอยู่ด้วยเช่น เซิร์ฟเวอร์ หรือ ฐานข้อมูล 

รหัสของช่องโหว่ครั้งนี้คือ CVE-2018-2636 ซึ่งถูกจัดค่าความรุนแรงอยู่ที่ 8.1 และผลของ Bug นี้คือทำให้แฮ็กเกอร์สามารถใช้ช่องโหว่จากภายนอกได้โดยไม่ต้องพิสูจน์ตัวตนในการอ่านไฟล์บนระบบ PoS ที่มีช่องโหว่ นอกจากนั้นแฮ็กเกอร์ยังสามารถเข้าถึงไฟล์ตั้งค่าของระบบที่ภายในเก็บข้อมูลรหัสผ่านไว้ด้วย ซึ่งทาง ERPScan ผู้เชี่ยวชาญด้านการรักษาความปลอดภัย Oracle และ SAP เผยว่าแฮ็กเกอร์สามารถใช้ช่องโหว่นี้เพื่อได้รับสิทธิ์อย่างเต็มที่ในการเข้าถึงระบบปฏิบัติการเพื่อใช้ทำลายหรือปลอมแปลง ซึ่งข้อมูลที่แฮ็กเกอร์อาจจะได้รับคือเลขบัตรเครดิต เป็นต้น

เนื่องด้วยระบบ Micros PoS มีลูกค้าลงทะเบียนใช้งานกับการจ่ายเงินบัตรเครดิตและเดบิตกว่า 3 แสนราย มากกว่า 2 แสนรายเป็นร้านอาหารและเครื่องดื่ม รวมถึงโรงแรมกว่า 3 หมื่นแห่งใน 180 ประเทศ แพตซ์นี้จึงสำคัญอย่างยิ่ง อย่างไรก็ตามระบบส่วนใหญ่ไม่สามารถใช้ช่องโหว่ผ่านอินเทอร์เน็ตได้หากตั้งค่าระบบดีพอ แต่ด้วยความที่มันยังมีช่องโหว่แฮ็กเกอร์อาจจะใช้การเข้าถึงอุปกรณ์เครือข่ายภายในร้านก่อนหรือเข้าถึงหน้าร้านเพื่อใช้งานช่องโหว่นี้ได้

นอกจากนี้ด้วยความสำคัญของระบบ PoS ผู้ดูแลระบบส่วนใหญ่จึงไม่ค่อยอยากยุ่งกับระบบเท่าไหร่นักเพราะกลัวเรื่องความไม่สเถียรของแพตซ์อาจส่งผลให้เกิด Downtime ซึ่งทำให้บริษัทเสียรายได้

ที่มา : https://www.bleepingcomputer.com/news/security/security-bug-affects-over-300-000-oracle-pos-systems/ และ http://www.securityweek.com/remotely-exploitable-vulnerability-could-impact-300000-oracle-pos-systems

from:https://www.techtalkthai.com/oracle-patch-micros-pos-bug-impact-payment-over-300000/

Advertisements

Oracle ออก Critical Patch Update แรกปี 2018 อุดช่องโหว่ 237 รายการบนกว่า 100 ผลิตภัณฑ์

Oracle ผู้ให้บริการระบบฐานข้อมูลและ Cloud ชื่อดัง ออก Critical Patch Update (CPU) เดือนมกราคม 2018 สำหรับอุดช่องโหว่ Meltdown, Spectre และอื่นๆ รวม 237 รายการบนผลิตภัณฑ์มากกว่า 100 ผลิตภัณฑ์ ไม่เว้นแม้แต่ Oracle Database Server และ Java SE

แพตช์ที่น่าสนใจ ได้แก่

  • แพตช์สำหรับ Java Virtual Machine และช่องโหว่บน Oracle Database Server อีก 4 รายการ ซึ่งช่องโหว่ที่รุนแรงที่สุดมี CVSS 9.1/10 ส่วนอีก 3 ช่องโหว่ที่เหลือช่วยให้แฮ็กเกอร์สามารถเจาะระบบจากระยะไกลโดยไม่ต้องพิสูจน์ตัวตนได้
  • แก้ปัญหาช่องโหว่บน Java SE เวอร์ชัน 6 – 9 รวม 21 รายการ ซึ่ง 18 รายการสามารถโจมตีได้ทันทีโดยไม่ต้องพิสูจน์ตัวตน ในขณะที่ช่องโหว่ที่มีความรุนแรงสูงสุดมี CVSS 8.3/10
  • อุดช่องโหว่ Deserialization 2 รายการที่ Waratek ค้นพบบนแพลตฟอร์ม Java
  • อุดช่องโหว่ Meltdown และ Spectre บนชิป Intel

ที่น่าสนใจคือ ช่องโหว่บนแพลตฟอร์ม Java มีจำนวนเพิ่มขึ้นถึง 2 เท่าเมื่อเทียบกับ CPU เมื่อเดือนมกราคม 2016 ซึ่งแสดงให้เห็นถึงแนวโน้มความไม่มั่นคงปลอดภัยของ Java ที่สำคัญคือ 86% ของแพตช์ที่มีระดับความรุนแรงสูงใช้เวลานานกว่า 30 วันถึงจะได้รับการติดตั้ง ในขณะที่แพตช์อื่นๆ ใช้เวลาอัปเดตโดยเฉลี่ยนานกว่า 90 วัน ส่งผลให้องค์กรทั้งหลายที่ใช้แพลตฟอร์ม Java ตกอยู่ในความเสี่ยงสูง

แนะนำให้ผู้ดูแลระบบวางแผนดำเนินการอัปเดตแพตช์โดยเร็ว

รายละเอียดเพิ่มเติม: http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html

ที่มา: https://www.helpnetsecurity.com/2018/01/17/oracle-cpu-january-2018

from:https://www.techtalkthai.com/oracle-releases-critical-patch-update-jan-2018/

พบช่องโหว่ร้ายแรงบน phpMyAdmin เสี่ยงฐานข้อมูลถูกโจมตี

Ashutosh Barot นักวิจัยด้านความมั่นคงปลอดภัยจากอินเดีย ออกมาแจ้งเตือนถึงช่องโหว่ Cross-site Request Forgery (CSRF) บน PhpMyAdmin เวอร์ชัน 4.7.x ซึ่งช่วยให้แฮ็กเกอร์สามารถสั่งการระบบฐานข้อมูลได้จากระยะไกล เพียงแค่หลอกให้ผู้ดูแลระบบกดคลิกลิงค์เท่านั้น

CSRF เป็นการโจมตีเว็บแอปพลิเคชันรูปแบบหนึ่ง ซึ่งแฮ็กเกอร์จะใช้วิธีการหลอกผู้ใช้ที่พิสูจน์ตัวตนเข้าสู่ระบบแล้ว ดำเนินการบางอย่างตามที่ตนต้องการ เช่น ผู้ใช้กำลังเข้าสู่ระบบ Internet Banking ถูกหลอกให้คลิกลิงค์เพื่อทำธุรกรรมการเงินให้แฮ็กเกอร์ เป็นต้น

ช่องโหว่ CSRF ที่ค้นพบนี้ ช่วยให้แฮ็กเกอร์สามารถสร้าง URL แบบพิเศษขึ้นมาก แล้วหลอกให้ผู้ดูแลระบบ phpMyAdmin กดคลิกเพื่อดำเนินคำสั่งบนระบบฐานข้อมูลได้ เช่น ลบข้อมูลในฐานข้อมูล หรือแม้แต่ลบ Table ฐานข้อมูลทิ้งไปเลย อย่างไรก็ตาม การโจมตีผ่านช่องโหว่ดังกล่าวยังมีเงื่อนไขที่ยุ่งยากอย่างหนึ่ง คือ แฮ็กเกอร์ต้องรู้จักชื่อของฐานข้อมูลและ Table ก่อน จึงจะสามารถสั่ง Insert, Drop หรือคำสั่งอื่นๆ ที่ต้องระบุชื่อเหล่านั้นได้

วิดีโอด้านล่างสาธิตการลบ (Drop) Table ของฐานข้อมูลทิ้งผ่านทางการหลอกให้ผู้ดูแลระบบคลิกลิงค์ที่สร้างขึ้นมาเป็นพิเศษ โดยที่ผู้ดูแลระบบไม่รู้ตัว

ช่องโหว่นี้ส่งผลกระทบบน phpMyAdmin เวอร์ชัน 4.7.6 หรือก่อนหน้านั้น ซึ่งทาง Barot ได้รายงานช่องโหว่ดังกล่าวไปยังทีมผู้พัฒนาของ phpMyAdmin ซึ่งก็ได้ออกแพทช์เวอร์ชันใหม่ คือ 4.7.7 เพื่อแก้ไขปัญหาเรียบร้อย แนะนำให้ผู้ดูแลระบบอัปเดตโดยเร็ว

รายละเอียดเพิ่มเติม: http://cyberworldmirror.com/vulnerability-phpmyadmin-lets-attacker-perform-drop-table-single-click/

ที่มา: https://thehackernews.com/2018/01/phpmyadmin-hack.html

from:https://www.techtalkthai.com/phpmyadmin-csrf-vulnerability-lead-to-database-attack/

พบการโจมตี MongoDB เรียกค่าไถ่ระลอกใหม่ ผู้ใช้กว่า 26,000 รายตกเป็นเหยื่อ

Dylan Katz และ Victor Gevers สองนักวิจัยด้านความมั่นคงปลอดภัยออกมาแจ้งเตือนถึงการโจมตี MongoDB เพื่อเรียกค่าไถ่หรือที่รู้จักกันในนาม MongoDB Apocalypse ระลอกใหม่ ที่เกิดขึ้นเมื่อสุดสัปดาห์ที่ผ่านมา ซึ่งขณะนี้มีผู้ตกเป็นเหยื่อแล้วมากกว่า 26,000 ราย

MongoDB Apocalypse ถูกตรวจพบครั้งแรกเมื่อช่วงปลายเดือนธันวาคม 2016 จนถึงเดือนมกราคม 2017 ที่ผ่านมา โดยกลุ่มแฮ็คเกอร์ได้สแกนระบบอินเทอร์เน็ตเพื่อค้นหาฐานข้อมูล MongoDB ที่เปิดการเชื่อมต่อจากภายนอก จากนั้นเจาะผ่านช่องโหว่เพื่อลบข้อมูลภายใน และแนบข้อความเรียกค่าไถ่แลกกับการได้ข้อมูลกลับคืนมา ซึ่งจากการตรวจสอบพบพบว่าฐานข้อมูลส่วนใหญ่ที่ถูกแฮ็คเป็นฐานข้อมูลที่ใช้ทดสอบ แต่บางระบบมีข้อมูลการใช้งานจริงอยู่ ส่งผลให้บางบริษัทยอมจ่ายค่าไถ่ อย่างไรก็ตาม ค้นพบภายหลังว่าการเรียกค่าไถ่แลกกับข้อมูลเป็นเรื่องหลอกลวง เนื่องจากข้อมูลทั้งหมดถูกลบไปเรียบร้อยแล้ว

จากเหตุการณ์ครั้งนั้นค้นพบว่ากลุ่มแฮ็คเกอร์สามารถโจมตีฐานข้อมูล MongoDB ไปเป็นจำนวนมากถึง 45,000 เครื่อง จากนั้นการโจมตีก็เริ่มลดลงจนแทบจะหายไป อย่างไรก็ตาม เมื่อสุดสัปดาห์ที่ผ่านมาพบว่ามีกลุ่มแฮ็คเกอร์อย่างน้อย 3 กลุ่มได้เริ่มโจมตี MongoDB เพื่อเรียกค่าไถ่ระลอกใหม่ โดยมีผู้ตกเป็นเหยื่อแล้วกว่า 26,000 ราย ซึ่งหนึ่งในสามกลุ่มนั้นสามารถโจมตีเป้าหมายได้มากถึง 22,000 เครื่อง

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

นอกจากนี้ Gevers ยังค้นพบอีกว่า หลังจากที่กลุ่มแฮ็คเกอร์เข้าควบคุมฐานข้อมูลของเหยื่อได้แล้ว เหยื่อพยายาม Restore ฐานข้อมูลกลับขึ้นมาใหม่จาก Backup ที่มีอยู่ ซึ่งน่าจะจบไป แต่เขากลับพบว่าฐานข้อมูลนั้นถูกโจมตีอีกครั้งในวันเดียวกัน เนื่องจากเหยื่อขาดทักษะหรือไม่สามารถหามาตรการควบคุมมาป้องกันการโจมตีของแฮ็คเกอร์ได้ทันท่วงที

ที่มา: https://www.bleepingcomputer.com/news/security/massive-wave-of-mongodb-ransom-attacks-makes-26-000-new-victims/

from:https://www.techtalkthai.com/new-wave-of-mongodb-attacks-make-26000-victims/

MariaDB แนะ 5 แนวทางเบื้องต้นสำหรับ Database Security

ใน Blog ของ MariaDB ได้มีการสรุปถึง 5 แนวทางพื้นฐานสำหรับ Database Security เอาไว้ ทางทีมงาน TechTalkThai เห็นว่าน่าสนใจดี จึงขอหยิบยกมาสรุปให้ได้อ่านกันดังนี้ครับ

Credit: MariaDB

 

1. ป้องกันการโจมตีด้วยการใช้ Database Proxy

การใช้ Database Proxy เป็นกลางคั่นระหว่าง Application และ Database ก่อนจะทำให้สามารถควบคุมและเสริมความมั่นคงปลอดภัยในการเข้าถึง Database ได้ โดยทาง MariaDB แนะนำให้ใช้ MaxScale ที่จะช่วยคัดกรองการเข้าถึง, รองรับการติดตั้งโมดูลเสริมสำหรับความสามารถต่างๆ เช่น การเพิ่มความมั่นคงปลอดภัย, การเพิ่มความทนทาน, การรองรับการเพิ่มขยาย และการเสริมประสิทธิภาพของระบบ เป็นต้น

MaxScale Database Firewall Filter เป็นความสามารถหนึ่งที่ทาง MariaDB แนะนำเป็นอย่างมาก โดยผู้ใช้งานสามารถทำการกำหนด Whitelist ของ Query รูปแบบต่างๆ เอาไว้ได้ ทำให้ Query ที่ผิดไปจากที่กำหนดไม่สามารถเข้าถึง Database ได้เลย อีกทั้ง MaxScale ยังสามารถใช้ปกป้อง Database จากการถูก DDoS ได้อีกด้วย

 

2. ตั้งค่าระบบ Audit Log ให้เรียบร้อย

การเปิด Audit Log จะช่วยให้มีข้อมูลในการตรวจสอบค้นหาพฤติกรรมต้องสงสัยและวิเคราะห์ต้นเหตุของปัญหาต่างๆ ได้มากขึ้น อีกทั้งยังตอบโจทย์การทำ Compliance อย่างเช่น GDPR, PCI, HIPAA และ SOX ได้ โดยทาง MariaDB แนะนำให้ใช้ MariaDB Audit Plugin ที่สามารถช่วยบันทึกข้อมูลจำนวนมากได้ ไม่ว่าจะเป็น Incoming Connection, Query Execution และการเข้าถึง Table ทั้งหมด ทำให้ทราบข้อมูลทั้งหมดว่าใครทำอะไรกับฐานข้อมูลบ้าง และยังสามารถเลือกได้ว่าจะบันทึก Log ทั้งหมดนี้ลง File หรือจะส่งออกไปทาง Syslog ก็ได้

 

3. จัดการกับ Account ของผู้ใช้งานให้ดี

ประเด็นนี้เป็นสิ่งที่ทาง MariaDB แนะนำว่าให้ทำอย่างระมัดระวัง โดยใช้หลักการเหมือนกับการจัดการ User Account อย่างมั่นคงปลอดภัยตามวิธีมาตรฐาน และแบ่งคำแนะนำออกเป็น 4 ข้อหลักๆ ด้วยกัน ดังนี้

  • อนุญาตให้เกิด Root Access ได้จากเฉพาะใน Local Client เท่านั้น
  • ตั้งรหัสผ่านให้เข้มแข็ง มั่นคงปลอดภัย
  • สร้าง User Account แยกสำหรับแต่ละ Application ให้ชัดเจน
  • จำกัด IP Address ที่สามารถเชื่อมต่อมายัง Database Server ได้ให้เหลือเท่าที่จำเป็น

 

4. หมั่นอัปเดต Database และ OS ให้เป็นรุ่นล่าสุดอยู่เสมอ

MariaDB กล่าวว่าการอัปเดตระบบเหล่านี้ให้เป็นรุ่นล่าสุดอยู่เสมอ เป็นหนทางเดียวที่จะปกป้องระบบจากภัยคุกคามล่าสุดที่ปรากฏขึ้นมาใหม่ได้ โดยการอัปเดตนี้ต้องทำทั้ง Database Software และที่ Operating System (OS) เลย รวมถึง Server Software อื่นๆ ที่มีการใช้งานอยู่ด้วยเช่นกัน

 

5. เข้ารหัสข้อมูลสำคัญทั้งหมด ตั้งแต่ภายใน Application, ระหว่างส่งผ่านเครือข่าย และการเข้ารหัสสำหรับ Data at Rest

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

  1. การเข้ารหัสภายใน Application ตั้งแต่ก่อนถูกบันทึกลงไปยัง Database ทำให้ถึงแม้ Hacker จะเจาะระบบ Database ได้สำเร็จ ก็จะยังเข้าถึงข้อมูลที่แท้จริงไม่ได้อยู่ดี
  2. การเข้ารหัสที่ระบบเครือข่าย เพื่อให้การส่งข้อมูลจาก Client ไปยัง Database นั้นมีความมั่นคงปลอดภัยมากขึ้น
  3. การเข้ารหัสสำหรับ Data at Rest เช่น การเข้ารหัส InnoDB Table Space, InnoDB Redo Log และ Binary Log ซึ่งความสามารถเหล่านี้สนับสนุนใน MariaDB 10.1 เป็นต้นไป

 

สำหรับผู้ที่ยังต้องการศึกษาข้อมูลเพิ่มเติมเกี่ยวกับ Database Security ทาง MariaDB ก็ได้ทิ้งท้ายเอาไว้ว่าให้ไปโหลด Whitepaper ที่ http://go.mariadb.com/GLBL-WC2017AdvancedSecurityWhitePaper_LP-Registration.html อ่านเพิ่มเติมครับ โดยในนี้จะสรุปถึงแนวโน้มเกี่ยวกับการโจมตี Database, การเข้ารหัสข้อมูล, เทคโนโลยี Database Firewall และ Data Masking, การป้องกัน DoS, การนำ RBAC/PAM และ User/Group Mapping มาใช้, การทำ Audit และการทำ Database Event Monitoring ครับ

 

ที่มา: https://mariadb.com/resources/blog/5-essential-practices-database-security

from:https://www.techtalkthai.com/5-practices-for-database-security-by-mariadb/

Database Activity Monitoring: 5 สิ่งที่ควรทำได้และไม่ควรทำ

Imperva ผู้ให้บริการโซลูชัน Database Security ชื่อดัง ออกมาให้คำแนะนำเกี่ยวกับสิ่งที่พึงกระทำและไม่พึงกระทำในการติดตามและเฝ้าระวังระบบฐานข้อมูล รวมไปถึงสรุปฟีเจอร์สำคัญที่เครื่องมือ Database Activity Monitoring ควรมีจากเอกสาร Understanding and Selecting a Database Activity Monitoring Solution โดย Rich Mogull จาก SANS Institute เพื่อให้ผู้ดูแลระบบฐานข้อมูลสามารถนำไปปรับใช้กับองค์กรของตนได้

Credit: macro vectors/Shutterstock

ก่อนที่จะเข้าสู่เนื้อหา ทำความรู้จัก Database Activity Monitoring (DAM) สักเล็กน้อย … Gartner ได้นิยาม DAM ไว้ว่า “เป็นชุดเครื่องมือที่ … รองรับความสามารถในการตรวจจับและรายงานการหลอกลวง การกระทำที่ผิดกฎหมาย หรือพฤติกรรมที่ไม่พึงประสงค์อื่นๆ ซึ่งส่งผลกระทบต่อการปฏิบัติงานของผู้ใช้และผลิตภาพน้อยที่สุด” หรืออาจกล่าวได้ว่าเป็นเครื่องมือที่พัฒนาจากการวิเคราะห์การกระทำของผู้ใช้ กลายเป็นเครื่องมือชี้วัดด้านความมั่นคงปลอดภัยของข้อมูล เช่น การค้นหาและจำแนกประเภทข้อมูล การบริหารจัดการสิทธิ์ของผู้ใช้ การติดตามการใช้สิทธิ์ระดับสูง การปกป้องข้อมูล และการป้องกันการรั่วไหลของข้อมูล เป็นต้น

Imperva ได้สรุปรายการฟีเจอร์ขั้นต่ำที่เครื่องมือ DAM ควรมี ดังนี้

  • ติดตาม (Monitor) และตรวจสอบ (Audit) การกระทำบนฐานข้อมูลทั้งหมดอย่างอิสระ ทั้งการกระทำที่ต้องใช้สิทธิ์ Admin และ SELECT Query Transactions เครื่องมือที่ใช้ต้องสามารถบันทึก SQL Transactions ได้ทั้งหมด ไม่ว่าจะเป็น DML, DDL, DCL (และบางกรณีอาจจะมี TCL ด้วย) โดยไม่จำเป็นต้องพึงหา Log ของ Local Database ซึ่งช่วยให้ประสิทธิภาพของฐานข้อมูลตกลงน้อยกว่า 0 – 2%
  • จัดเก็บ Audit Log แบบรวมศูนย์ภายนอกฐานข้อมูลที่ทำการตรวจสอบ และต้องเก็บอย่างมั่นคงปลอดภัย
  • ติดตาม รวบรวม และเชื่อมความสัมพันธ์ของการกระทำจากหลายๆ Database Management System (DMBS) ที่แตกต่างกันได้ เช่น Oracle, Microsoft SQL Server และ IBM DB2 รวมไปถึงสามารถแปลง Transaction ให้กลายเป็นรูปมาตรฐานทั่วไปที่นำไปใช้วิเคราะห์ต่อได้ (ทำ Normalization)
  • กำหนดหมายเลข IP ที่อนุญาตให้ใช้งาน Service Account เพื่อเข้าถึงฐานข้อมูล รวมไปถึงกำหนดสิทธิ์เฉพาะเท่าที่จำเป็น
  • บังคับให้มีการแบ่งแยกหน้าที่การทำงาน (Segegration of Duties) ผ่านทางการติดตามและบันทึกหลักฐานการกระทำของ DBA
  • สร้างระบบแจ้งเตือนแบบ Rule-based หรือ Heuristic-based เมื่อมีการละเมิดนโยบายด้านความมั่นคงปลอดภัย เช่น แจ้งเตือนเมื่อผู้มีสิทธิ์ระดับสูงส่ง SQL Query ซึ่งคืนค่าข้อมูลบัตรเครดิตกลับคืนมาเกิน 5 รายการ เป็นต้น เพื่อช่วยแจ้งเตือนผู้ดูแลระบบเมื่อแอพพลิเคชันถูกแฮ็คหรือถูก SQL Injection

นอกจากนี้ เครื่องมือ DAM บางยี่ห้อยังมีฟีเจอร์

  • ค้นหาและตรวจสอบที่อยู่ ขนาด และบริบทของข้อมูลที่จัดเก็บอยู่ใน Data Center บนระบบ Cloud หรือบนฐานข้อมูลแบบเก่า
  • จำแนกประเภทของข้อมูล เช่น หมายเลขบัตรเครดิต อีเมล บันทึกการแพทย์ รวมไปถึงระดับความเสี่ยงของข้อมูลดังกล่าว
  • จัดทำนโยบายหรือรายงานตามข้อกำหนดต่างๆ เช่น PCI-DSS หรือ SOX ได้
  • ผสานการทำงานร่วมกับเครื่องมือทำ Change Management เพื่อติดตามการเปลี่ยนแปลงข้อมูลในฐานข้อมูล หรือติดตามการกระทำของ DBA รวมไปถึงจัดทำรายงาน Change Management
Credit: Viappy/ShutterStock

สำหรับรายการสิ่งที่พึงกระทำและไม่พึงกระทำในการติดตามและเฝ้าระวังระบบฐานข้อมูล มีทั้งหมดอย่างละ 5 ข้อ ได้แก่

สิ่งที่พึงกระทำ

  • Agent ที่ใช้ในการเก็บข้อมูลควรบริโภคทรัพยากร CPU และ Disk เพียง 1 – 3% และควรใช้ Agent เก็บข้อมูลแทนที่จะวางขวาง (Bridge) หรือดักจับข้อมูล (Sniff) เนื่องจากสามารถทำคลัสเตอร์ Gateway ได้ง่าย เพราะเพิ่มประสิทธิภาพในการทำ HA ฐานข้อมูล
    • หมายเหตุ การบริโภคทรัพยากรนี้ถือว่าน้อยมากเมื่อเทียบกับการใช้ Database Auditing บนระบบฐานข้อมูลซึ่งบริโภคทรัพยากรเครื่องมากถึง 20%
  • ติดตาม Local SQL Traffic อย่างต่อเนื่อง และอย่างเรียลไทม์ เช่น IPC และ Bequeth รวมไปถึงติดตาม SQL Traffic ที่วิ่งเข้ามายังฐานข้อมูลผ่านระบบเครือข่าย (ถ้าต้องการ)
  • ยิง TCP Reset เมื่อต้องการบล็อกเซสชัน ซึ่งจะทำให้เสมือนว่าเครื่อง Client หลุดจากการเชื่อมต่อ ผลลัพธ์คือ ฐานข้อมูลไม่มีอะไรเปลี่ยนแปลงและเครื่อง Client ที่เชื่อมต่อกับฐานข้อมูลจะถูกจัดการตามปกติ
  • ติดตาม SQL Query ขาเข้าที่จะไปยัง Gateway รวมไปถึงข้อมูล Metadata บางอย่าง เช่น เวลาที่ใช้ตอบสนอง หรือจำนวน Record ที่คืนกลับมา โดยกิน Bandwidth ของระบบเครือข่ายให้น้อยที่สุด
    • หมายเหตุ สามารถติดตามทราฟฟิกขาออกผ่านทางอีกอินเทอร์เฟสหนึ่ง แต่ต้องระวังเรื่องการดักจับข้อมูลที่เป็นความลับด้วย
  • ควรมีหน้า Dashboard ที่เป็นกราฟิกแสดงภาพรวมข้อมูลทั้งหมดไว้ในหน้าเดียว เพื่อให้สามารถแก้ปัญหาได้ง่ายและรวดเร็ว โดยต้องสามารถตรวจสอบการทำงานของ Agent และสามารถแจ้งเตือนไปยังระบบอื่นๆ เช่น SIEM เมื่อมีการบล็อกเกิดขึ้นได้

สิ่งที่ไม่พึงกระทำ

  • Agent ไม่ควรติดตั้ง Object ใดๆ บนฐานข้อมูล เช่น สคริปต์หรือข้อมูลล็อกอิน
  • Agent ต้องไม่ยุ่งเกี่ยวใดๆ กับฐานข้อมูล ไม่ว่าจะเป็นข้อมูลในฐานข้อมูล ไฟล์ที่ใช้ตั้งค่าฐานข้อมูล หรือแม้แต่พารามิเตอร์ของฐานข้อมูล
  • หลังติดตั้งหรือแก้ไขการตั้งค่า Agent ไม่ควรมีการรีสตาร์ทเครื่อง เว้นแต่ในกรณีที่หลีกเลี่ยงไม่ได้จริงๆ
  • ไม่ควรมีการสร้างชื่อบัญชีฐานข้อมูลใหม่สำหรับติดตั้ง ติดตาม หรือบล็อก SQL Traffic บน Agent
  • Agent ไม่ควรแก้ไขไฟล์ของระบบ เว้นแต่ในกรณีที่การเชื่อมต่อไปยัง Gateway ถูกตัดขาดจากการบล็อก และควรกลับไปเป็นแบบเดิมหลังจากที่การเชื่อมต่อถูกสร้างขึ้นมาใหม่

ที่มา: https://www.imperva.com/blog/2017/05/database-activity-monitoring-checklist/

from:https://www.techtalkthai.com/database-activity-monitoring-checklist/

พบช่องโหว่ Zero-day บน SAP HANA เสี่ยงถูกเข้าควบคุมแบบ Full Access

Onapsis บริษัทที่ปรึกษาด้านความมั่นคงปลอดภัยระบบ SAP ออกมาเปิดเผยถึงช่องโหว่ Zero-day ความเสี่ยงสูงบนแพลตฟอร์ม SAP HANA ซึ่งช่วยให้แฮ็คเกอร์สามารถเข้าควบคุม SAP HANA จากระยะไกลโดยไม่จำเป็นต้องพิสูจน์ตัวตนก่อนได้ แนะนำให้ผู้ดูแลระบบ SAP HANA รีบอัปเดตแพทช์โดยเร็ว

Credit: Pavel Ignatov/ShutterStock

Sebastian Bortnik หัวหน้าทีมวิจัยของ Onapsis ระบุใน Blog เกี่ยวกับช่องโหว่ดังกล่าวว่า การเจาะช่องโหว่เพื่อเข้าควบคุมระบบ SAP HANA นี้ช่วยให้แฮ็คเกอร์สามารถดำเนินกิจกรรมได้ทุกอย่างบนข้อมูลและกระบวนการเชิงธุรกิจของ SAP HANA ไม่ว่าจะเป็นการขโมยข้อมูลออกมาจากระบบ การเปลี่ยนแปลง แก้ไข หรือลบข้อมูลทิ้ง เรียกได้ว่าเป็นช่องโหว่ความรุนแรงระดับ Critical ที่ส่งผลกระทบต่อธุรกิจอย่างใหญ่หลวง

ช่องโหว่นี้ค้นพบบนฟีเจอร์ของ SAP HANA ที่ชื่อว่า SAP HANA User Self Service ซึ่งเป็นฟีเจอร์ที่ไม่ได้เปิดใช้งานมาตั้งแต่เริ่มแรก ผู้ใช้ต้องเปิดใช้งานเอง โดยเวอร์ชันของ SAP HANA ที่ได้รับผลกระทบ ได้แก่

  • SAP HANA SPS 12 (newDB rel 1.00.121.00.1466466057)
  • SAP HANA 2 SPS0 (newDB rel 2.00.000.00.1479874437)
  • SAP HANA SPS11 (1.00.110.144775) ออกเมื่อเดือนพฤศจิการยน 2015
  • SAP HANA SPS10 (1.00.101.00.1435831848) ออกเมื่อเดือนมิถุนายน 2015
  • SAP HANA SPS09 (1.00.91.1418659308) ออกเมื่อเดือนพฤศจิการยน 2014

Onapsis ระบุว่า ช่องโหว่ดังกล่าวคาดว่ามีมาแล้วไม่ต่ำกว่า 2 ปีครึ่งนับตั้งแต่เริ่มมีฟีเจอร์ User Self Service ให้บริการ โดยค้นพบช่องโหว่ทั้งบน SAP HANA 2 เวอร์ชันใหม่ล่าสุด ไปจนถึง SAP HANA เวอร์ชันปี 2014 ซึ่งแนะนำให้ผู้ใช้ SAP HANA ตรวจสอบว่าบริษัทของตนเปิดใช้ฟีเจอร์ที่มีช่องโหว่หรือไม่ ถ้าเปิดใช้ทำงานให้รีบอัปเดตแพทช์ตาม SAP Security Note #2424173 หัวข้อ “Vulnerabilities in the User Self-Service Tools of SAP HANA” และ Security Note #2429069 โดยเร็ว

ที่มา: https://www.onapsis.com/blog/sap-security-notes-march-2017-onapsis-helps-secure-critical-bugs-sap-hana

from:https://www.techtalkthai.com/zero-day-sap-hana-vuln-allowed-full-access/