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

Amazon ออก GuardDuty ฟีเจอร์ใหม่เพื่อตรวจจับและติดตามภัยคุกคาม

Amazon ได้ออกฟีเจอร์เพื่อช่วยให้ระบบ IT ปลอดภัยจากภัยคุกคามที่อาจะเกิดขึ้น โดยการใช้เทคโนโลยี Machine Learning เรียนรู้จากข้อมูลที่ Amazon สร้างขึ้น ซึ่งตัว GuardDuty เองได้วิเคราะห์ข้อมูลกว่าพันล้านเหตุการณ์เพื่อเข้าใจถึงเทรน รูปแบบ และความผิดปกติที่อาจจะเป็นสัญญานของความผิดพลาด นอกจากนี้ผู้ใช้งานยังสามารถดูสิ่งหาเจอได้อย่างรวดเร็ว

credit : AWS Blog

วิธีการทำงาน

GuardDuty ใช้ข้อมูลปริมาณมหาศาลประกอบด้วย แหล่งข้อมูลที่มีหลักฐาน (Threat Intelligence) จากหลายแห่ง, โดเมนที่หลอกหลวง, IP address ของมัลแวร์ และปัจจัยอื่นๆ ที่สำคัญ ให้ระบบเรียนรู้เพื่อที่จะสามารถระบุพฤติกรรมที่ไม่ได้รับการพิสูจน์ตัวตนหรือไม่เหมาะสมต่อบัญชี AWS ของผู้ใช้ได้อย่างแม่นยำ นอกจากนี้ด้วยการผสานข้อมูลจากฟีเจอร์ของ VPC Flow Logs (เก็บ Log IP ที่ผ่านเข้าออกระบบเครือข่ายของผู้ใช้งาน) รวมกับ CloudTrail Event Logs (เก็บ Log ในรูปแบบของ Jason เพื่อ) และ DNS Logs ทำให้ GuardDuty สามารถตรวจพบพฤติกรรมที่อันตรายหรือผิดปกติเช่น การแสกนหาช่องโหว่ การแสกนพอร์ต และเข้าถึงจากสถานที่ไม่คุ้นเคย

ในฝั่งของ AWS เองจากคอยดูกิจกรรมต้องสงสัยของบัญชีต่างๆ เช่น การติดตั้งที่ไม่ได้รับการพิสูจน์ตัวตน กิจกรรมใน CloudTrail ที่แตกต่างจากเดิม รูปแบบของการใช้งาน API ใน AWS และความพยายามในการขยายข้อจำกัดของบริการต่างๆ ส่วน GuardDuty จะคอยตรวจสอบการแทรกแทรง EC2 ที่เกิดจากองค์ประกอบหรือบริการที่ผิดวัตถุประสงค์ รวมถึงการรั่วไหลของข้อมูลและการใช้ทรัพยากรเพื่อทำ Cryptocurrency Mining

ในด้านประสิทธิภาพ GuardDuty ตั้งอยู่บนโครงสร้างของ AWS เอง ซึ่งจะไม่ส่งผลกระทบต่อประสิทธิภาพในการทำงานของระบบผู้ใช้งาน นอกจากนี้ผู้ใช้ไม่จำเป็นต้องติดตั้ง Agent, Sensors หรืออุปกรณ์เครือข่ายเพื่อใช้งาน GuardDuty ดังนั้นมันเป็นโมเดลที่ทีมงานความมั่นคงปลอดภัยควรจะนำไปใช้งานกับบัญชีบน AWS เนื่องจากไม่ต้องทำอะไรเพิ่มเติมเลย

กิจกรรมที่ GuardDuty ค้นพบสามารถจำแนกได้ 3 ระดับคือ ต่ำ กลาง และสูง พร้อมทั้งให้รายละเอียดของหลักฐานและคำแนะนำในการแก้ไข โดยสิ่งที่ค้นพบนั้นจะปรากฎอยู่ใน Amazon CloudWatch Event (ฟังก์ชันติดตามการเปลี่ยนแปลงที่เกิดขึ้นกับทรัพยากรบน AWS) สิ่งนี้เองสามารถทำให้ผู้ใช้สามารถใช้งาน AWS Lambda ต่อเพื่อแก้ปัญหาได้อย่างอัตโนมัติ  นอกจากนี้ยังสามารถส่งเหตุการณ์ที่ GuardDuty ค้นพบไปยังระบบบริหารจัดการเหตุการณ์ เช่น Splunk, Sumo Logic, PagerDuty หรือระบบการทำงานอย่าง JIRA, ServiceNow และ Slack

ที่มา : https://aws.amazon.com/blogs/aws/amazon-guardduty-continuous-security-monitoring-threat-detection/

from:https://www.techtalkthai.com/amazon-offer-guardduty/

Advertisements

ข้อมูลลับสุดยอดของกองทัพสหรัฐและ NSA หลุดจาก Amazon S3

UpGuard บริษัทที่ให้บริการประเมินความเสี่ยงด้านความมั่นคงปลอดภัยได้พบเซิร์ฟเวอร์ S3 อีกตัวหนึ่งที่เป็นของหน่วยงานข่าวกรอง (INSCOM) ภายใต้ความดูแลของ NSA และกองทัพสหรัฐ สืบเนื่องจากเมื่อไม่กี่วันก่อนหน้านี้ UpGuard ได้พบข้อมูลรั่วไหลใน Amazon S3 ของ DOD ไปแล้วซึ่งมีข้อมูล Social Media จากคนทั่วโลกกว่า 1.8 พันล้านโพสต์ 

credit : Bleeping computer and UpGuard

นักวิจัยพบ VM ที่มีข้อมูลลับสุดยอด

นักวิจัยกล่าวว่าพบไฟล์เสมือนของเครื่อง Linux พร้อมกับ Virtual Hard drive (ที่เก็บข้อมูลของเครื่อง) แม้ว่าจะไม่สามารถนำบูตเครื่องขึ้นมาหรือเข้าถึงไฟล์ใน Virtual Hard drive ได้เนื่องจากมาตรการด้านความมั่นคงปลอดภัยของกลาโหม (DOD) ที่ให้เข้าถึงเครื่องได้จากเครือข่ายภายในเท่านั้น แต่อย่างไรก็ตามนักวิจัยสามารถค้นหาเนื้อหาของไฟล์ใน SSD image ที่เก็บข้อมูลสำคัญซึ่งบางไฟล์ที่ถูกจัดอยู่ในประเภทลับสุดยอดและความมั่นคงปลอดภัยของบุคคลต่างชาติ

ไฟล์ที่หลุดออกมามีร่องรอยของแพลตฟอร์ม Red Disk

ในโฟลเดอร์ของ VM ดังกล่าวได้ชี้ไปถึงระบบที่เป็นส่วนหนึ่งของ Red Disk หรือแพลต์ฟอร์มการประมวลผลของ Cloud ที่ถูกใช้ในระบบกระจายข่าวกรองภาคพื้นของกองทัพ (DGCS-A) โดยกระทรวงกลาโหม ซึ่งตอนแรก Red Disk ถูกคาดหวังว่าจะใช้เป็นศูนย์รวมข้อมูลของหน่วยข่าวกรองเพื่อให้กองทัพสหรัฐได้ค้นหาและเข้าถึงข้อมูลได้อย่างทันท่วงทีตามสิทธิ์ของผู้ใช้งาน โดยใช้เงินลงทุนไปกว่า $93 ล้านแต่ในขั้นตอนทดลองพบว่ามันช้าเกินรับได้ทาง DOD จึงได้ล้มเลิกไปเมื่อปี 2014

UpGuard กล่าวว่านี่เป็นครั้งแรกที่ค้นพบข้อมูลลับสุดยอดบน S3 ที่ถูกเปิดให้เข้าถึงได้อย่างอิสระ “การรั่วไหลของข้อมูลบน Cloud สามารถหลีกเลี่ยงได้ เหมือนกับข้อผิดพลาดที่เกิดขึ้นจากการขาดขั้นตอนเพื่อตรวจสอบบางสิ่งบางอย่างในระบบ IT” นอกจากนี้ UpGuard ยังตั้งคำถามว่าหน่วยงานรัฐบาลจะมั่นใจได้อย่างไรว่าข้อมูลเหล่านั้นถูกตั้งค่าได้อย่างถูกต้องและมีความมั่นคงปลอดภัย

ที่มา : https://www.bleepingcomputer.com/news/security/top-secret-us-army-and-nsa-files-left-exposed-online-on-amazon-s3-server/

from:https://www.techtalkthai.com/amazon-s3-leaked-data-of-nsa-and-us-army/

Uber แถลง Hacker ขโมยข้อมูลผู้ขับรถและผู้โดยสารทั่วโลกกว่า 57 ล้านรายการได้เมื่อปี 2016

นับเป็นข่าวใหญ่ไม่น้อยกับการแถลงของ Uber ว่าเมื่อปี 2016 ที่ผ่านมานั้นมี Hacker สามารถเข้าถึงฐานข้อมูลผู้ขับขี่รถยนต์และผู้โดยสารของ Uber ได้กว่า 57 ล้านรายการ และทาง Uber ในยามนั้นก็เลือกที่จะจ่ายค่าไถ่มูลค่า 100,000 เหรียญหรือราวๆ 3.5 ล้านบาท เพื่อให้ Hacker ลบข้อมูลเหล่านั้นทิ้งไปเสีย และปิดปากเงียบมาเป็นเวลากว่า 1 ปี

Credit: Ditty about summer/ShutterStock

 

การโจมตีครั้งนี้เกิดขึ้นตั้งแต่เดือนตุลาคม 2016 โดย Hacker สามารถเข้าถึงข้อมูลชื่อ, Email, ที่อยู่ และเบอร์โทรศัพท์ของผู้ใช้บริการ Uber กว่า 50 ล้านรายทั่วโลก อีกทั้งยังถูกเข้าถึงข้อมูลผู้ขับขี่รถยนต์ในระบบของ Uber อีกกว่า 7 ล้านราย และยังรวมถึงเลขใบขับขี่ของผู้ขับในสหรัฐอเมริกาอีกกว่า 600,000 รายการ อย่างไรก็ดี Uber ระบุว่าไม่มีข้อมูล Social Security Number, ข้อมูลบัตรเครดิต, ข้อมูลที่หมายปลายทาง หรือข้อมูลอื่นๆ ถูกขโมยแต่อย่างใด และเชื่อด้วยว่าข้อมูลที่ถูกขโมยไปนั้นก็ไม่ได้ถูกนำไปใช้งานด้วย

หลังจากที่ Uber จ่ายค่าไถ่ให้แก่ Hacker และปิดปากเงียบไปแล้วนั้น เมื่อ Dara Khosrowshani ได้ขึ้นมาดำรงตำแหน่ง CEO เมื่อเดือนกันยายน 2017 ที่ผ่านมา เขาก็เชื่อว่าการตัดสินใจปิดปากเงียบในเรื่องใหญ่ระดับนี้เป็นสิ่งที่ผิด และออกมายอมรับถึงปัญหานี้ในแถลงการณ์ เพราะตามกฎหมายแล้ว Uber จะต้องรายงานกรณีนี้แก่ผู้เกี่ยวข้องทางกฎหมาย และเหล่าผู้ขับขี่ที่ถูกขโมยข้อมูลออกไป

Uber ไม่ยอมเปิดเผยว่าผู้โจมตีรายนี้คือใคร และในเวลานี้ทางภาครัฐของสหรัฐอเมริกานั้นก็เริ่มเข้ามาสืบสวนเรื่องราวในครั้งนี้ต่อแล้ว โดยทาง Uber ได้ไล่ Joe Sullivan ผู้ดำรงตำแหน่ง Chief Security Officer และพนักงานอีกหนึ่งรายที่เกี่ยวข้องออกไปเป็นที่เรียบร้อย

สำหรับสาเหตุที่ทำให้ Uber ถูก Hack ในครั้งนี้นั้น ก็เกิดขึ้นจากการที่ผู้โจมตีสามารถเข้าถึง Code ของ Uber ที่ถูกเก็บอยู่บน Private GitHub ได้ และนำ Login Credential ภายในนั้นออกมาใช้เข้าถึง Data Store บน Amazon Web Services (AWS) ของ Uber นั่นเอง จากนั้น Hacker ก็ได้ทำการ Email แจ้งไปยังทาง Uber และเรียกค่าไถ่

ก่อนหน้านี้ Uber เคยมีกรณีที่ไม่ยอมเปิดเผยการเกิดเหตุ Data Breach เมื่อครั้งปี 2014 จนโดนศาลสั่งปรับมาแล้ว

 

ที่มา: https://www.bloomberg.com/news/articles/2017-11-21/uber-concealed-cyberattack-that-exposed-57-million-people-s-data

from:https://www.techtalkthai.com/uber-data-breach-leaks-57-million-information-of-its-worldwide-drivers-and-customers/

NIST ออกเอกสารแนวทาง Application Container Security Guide ให้นำไปศึกษาได้ฟรี

ด้วยกระแสของการนำ Container มาใช้งานในระดับ Production ทั้งโดยเหล่าผู้ให้บริการรายใหญ่และในระดับองค์กรที่เติบโตขึ้นเรื่อยๆ ทาง NIST จึงได้ออกเอกสารแนะแนวทางการทำ IT Security สำหรับ Container โดยเฉพาะด้วยกัน 3 ฉบับ ให้โหลดไปอ่านกันได้ฟรีๆ ดังนี้ครับ

Credit: ShutterStock.com

 

ส่วนทาง CoreOS นั้นก็ได้นำเสอนให้ทดลองใช้งาน Tectonic Sandbox เพื่อลองปฏิบัติตามแนวทางของ NIST กันได้ฟรีๆ ที่ https://coreos.com/tectonic/sandbox?utm_source=blog&utm_medium=referral ครับ โดย Tectonic Sandbox นี้สามารถใช้งานได้ฟรีๆ โดยไม่ต้องใช้ Cloud Credential ใดๆ และสามารถใช้งานได้บนทั้ง macOS, Windows และ Linux อีกด้วยครับ

 

ที่มา: https://coreos.com/blog/coreos-welcomes-nist-container-security-guidelines

from:https://www.techtalkthai.com/nist-application-container-security-guides-are-released/

นักข่าว BBC พบปัญหาบนบริการ Cloud ทำข้อมูล KPMG และ BBC รั่ว

นักข่าวจาก BBC ได้ค้นพบปัญหาทางด้านความมั่นคงปลอดภัยบนบริการ Cloud อย่าง Huddle ซึ่งทำให้ไฟล์ของผู้ใช้งานจาก KPMG และ BBC หลุดรั่วออกมา และประเด็นนี้ก็มีความน่าสนใจในเชิงเทคนิคอยู่ไม่น้อย

Credit: ShutterStock.com

 

Huddle นั้นเป็นบริการ Office Collaboration สำหรับให้พนักงานภายในองค์กรทำการแลกเปลี่ยนไฟล์และสื่อสารกันได้อย่างมั่นคงปลอดภัย แต่นักข่าว BBC รายนี้ได้ค้นพบปัญหาเมื่อเขาล็อกอินเข้าไปยัง Huddle เพื่อตรวจสอบ Calendar ของเพื่อนร่วมทีม แต่กลับถูก Redirect ไปยัง Account ของผู้ใช้งานรายอื่นซึ่งเป็นพนักงานของ KPMG แทน และสามารถเข้าถึงเอกสารทางด้านการเงินรวมถึงใบ Invoice ของ KPMG ได้

เมื่อเขาแจ้งปัญหานี้ไปยังทีมงานของ Huddle ทีมงานก็ได้อธิบายว่าเมื่อผู้ใช้งานทำการ Sign-in เข้าสู่ระบบ อุปกรณ์ของผู้ใช้งานนั้นจะทำการร้องขอ Authorization Code ซึ่งถ้าหากมีผู้ใช้งาน 2 คนทำการ Sign-in เข้าไปยัง Back-end Server เครื่องเดียวกันบน Cloud ภายในเวลาห่างกันไม่ถึง 20 Millisecond ผู้ใช้งานทั้งสองคนนั้นจะได้รับ Authorization Code เดียวกัน ซึ่งจะทำให้ผู้ใช้งานทั้ง 2 คนทำการยืนยันตัวตนเข้าไปยัง Account ของผู้ใช้งานคนแรก ถึงแม้ว่าผู้ใช้งานคนหลังไม่ควรจะมีสิทธิ์ก็ตาม และในที่นี้ก็ทำให้นักข่าว BBC รายนี้เข้าถึง Account ของพนักงาน KPMG ได้นั่นเอง

Huddle อ้างว่าบั๊กนี้ส่งผลกระทบต่อผู้ใช้งานจำนวนเพียง 6 Session เท่านั้นในช่วงเดือนมีนาคมถึงพฤศจิกายน 2017 ที่ผ่านมาจากจำนวนการ Log-in ทั้งสิ้น 4.96 ล้านครั้ง เรียกได้ว่าโอกาสเกิดขึ้นมีต่ำมาก แต่ Huddle ก็ได้เสริมด้วยว่าก่อนหน้านี้เคยมีผู้ใช้งานจากองค์กรอื่นสามารถ Log-in เข้าไปยัง Account ของ BBC ได้เช่นกัน แต่ไม่มีการเปิดไฟล์หรือเปิดอ่านข้อมูลใดๆ เกิดขึ้น

ล่าสุดทาง Huddle ได้ออกมาประกาศแล้วว่าบั๊กนี้ถูกแก้แล้วเรียบร้อย อย่างไรก็ดี Bill Evan จาก One Identity ที่ทำธุรกิจในสาย IT Security นั้นก็ได้ออกมาให้ความเห็นว่าบั๊กนี้เป็นปัญหาทางด้านความมั่นคงปลอดภัยที่ไม่ควรจะเกิดขึ้นกับบริษัทที่อ้างว่าบริการของตนเองมีความมั่นคงปลอดภัยสูง และลูกค้าของธุรกิจเหล่านี้ก็เป็นองค์กรใหญ่ระดับ KPMG ที่วางใจถึงขั้นนำข้อมูลความลับมาฝากเอาไว้บนบริการนี้เพื่อให้สื่อสารกันได้ง่ายขึ้น แต่เหตุการณ์นี้ก็อาจทำให้เกิดแรงต้านจากฝ่าย IT หรือ Infosec ของ KPMG ได้ ซึ่งเขาเองก็สันนิษฐานอีกว่ากรณีนี้จริงๆ แล้วอาจเป็น Shadow IT ที่เกิดขึ้นใน KPMG ก็เป็นได้เช่นกัน

เป็นบทเรียนว่าบั๊กเล็กๆ ถ้าเกิดกับนักข่าว เรื่องก็อาจไม่เล็กอีกต่อไปนะครับ

 

ที่มา: https://www.infosecurity-magazine.com/news/highly-secure-cloud-tool-huddle/

from:https://www.techtalkthai.com/bbc-journalist-found-security-flaw-on-huddle/

เตือนตั้งค่า AWS S3 ผิดพลาด เสี่ยงถูกโจมตีแบบ Man-in-the-Middle โดยไม่รู้ตัว

Sekhar Sarukkai หัวหน้าทีมนักวิจัยจาก Skyhigh Networks ออกมาเปิดเผยถึงวิธีการโจมตีใหม่บน Amazon S3 Bucket ซึ่งช่วยให้แฮ็คเกอร์สามารถโจมตีแบบ Man-in-the-Middle หรือแฮ็คเข้าไปยังบริษัทของลูกค้าผ่านทางการสแกนหา S3 บนอินเทอร์เน็ตที่เจ้าของไม่ได้จำกัดสิทธิ์การเขียน (Write Access) เอาไว้ โดยเรียกวิธีการโจมตีนี้ว่า ‘GhostWriter’

Credit: ShutterStock.com

GhostWriter แทนที่ไฟล์ปกติด้วยไฟล์อันตราย

แฮ็กเกอร์สามารถใช้ประโยชน์จากการตั้งค่า S3 ผิดพลาด (ไม่จำกัดสิทธิ์การเขียนไฟล์) โดยทำการแทนที่ไฟล์จริงด้วยไฟล์ที่ถูกดัดแปลงมาเป็นพิเศษเพื่อใช้โจมตีโดยเฉพาะ Sarukkai กล่าวว่า เจ้าของ Bucket ที่เก็บ JavaScript หรือโค้ดอื่นๆ ควรจะใส่ใจกับภัยคุกคามครั้งนี้ว่าไม่มีมือที่สามมาแอบเขียนทับโค้ดเหล่านั้นเพื่อใช้ในทางไม่ดีได้ เช่น โจมตีแบบ Drive-by Attacks, ขุดเหมือง Bitcoin หรือเจาะช่องโหว่ นอกจากนี้ยังให้รายละเอียดอีกว่าถ้าแฮ็กเกอร์ค้นพบ S3 ที่สิทธิ์การเขียนเป็นของบริษัทตัวแทน แฮ็กเกอร์ก็สามารถแทน Ad code (โค้ดของตัวแทนจำหน่าย) และเปลี่ยนให้เงินไปเข้าบัญชีของตัวเอง หรือดักจับและเปลี่ยนเส้นทางการชำระเงินของ Subscription ได้

GhostWriter คือวิธีการแฮ็กบริษัทอย่างไร้ร่องรอย

เทคนิค GhostWriter เป็นวิธีที่อันตรายมากเมื่อดำเนินการโจมตีแบบ Man-in-the-Middle และคอยดักจับข้อมูลที่วิ่งเข้ามา การโจมตีนี้ไร้ร่องรอยและตรวจพบได้ยาก เนื่องจากเป็นการโจมตีที่ใช้ประโยชน์จากองค์ที่เชื่อถือผู้ให้บริการระบบ Cloud นอกจากนี้เทคนิค GhostWriter สามารถนำไปใช้โจมตีได้ทั้งสองฝั่งไม่ว่าจะเป็นเครือข่ายภายในบริษัทเองหรือฝังคู่ค้าของบริษัทนั้นเพื่อขโมยข้อมูลสำคัญออกมา

เซิร์ฟเวอร์บน Cloud นั้นเป็นเป้าหมายที่มีค่าอย่างยิ่ง

การโจมตีแบบนี้ไม่ใช่เพียงแค่ในทฤษฎีอีกต่อไป เมื่อต้นปีนี้กลุ่มแฮ็กเกอร์จากจีนได้หมายหัวผู้ให้บริการ Cloud โดยเข้าไปแฝงตัวภายในผู้ให้บริการ Cloud บนระบบเครือข่ายภายใน เนื่องจากบริษัทส่วนใหญ่นิยมมาใช้ Cloud เพื่อทำดำเนินงาน เช่น แชร์เอกสาร แอปพลิเคชันภายในองค์กร ระบบฝ่ายบุคคล หรืออื่นๆ แต่ว่าก็ไม่ได้รับการยืนยันว่าเกิดจากเทคนิค GhostWriter หรือไม่ แต่เทคนิค GhostWriter นี้ก็ให้ผลเช่นเดียวกัน คือ แฮ็คเกอร์เสาะหา S3 Bucket ที่ต้องการแล้วก็ทำการแทรกซึมลึกลงไปภายในบริษัทต่างๆ โดยการแทนที่ไฟล์และปฏิบัติการ Man-in-the-Middle แบบลับๆ เพื่อดักจับข้อมูลที่ผ่านเข้ามา Dylan Katz นักวิจัยด้านความมั่นคงปลอดภัยระบุว่า “การโจมตีนี้คล้ายกับที่เคยเกิดขึ้นก่อนหน้าที่กลุ่มแฮ็คเกอร์จากรัสเซียชื่อ APT28 ได้ทำการแทนที่ไฟล์ปกติที่อยู่ในโฟลเดอร์ที่เปิดแชร์ด้วยเอกสารที่ติดมัลแวร์ ” Skyhigh ชี้ให้เห็นว่ากว่า 1,600 S3 Buckets สามารถเข้าถึงได้จากเครือข่ายภายในองค์กรและ 4% มีความเสี่ยงสูงจากการโจมตีแบบ GhostWriter เนื่องจากอนุญาติให้ผู้ใช้จากภายนอกที่ไม่ได้ผ่านการพิสูจน์ตัวตนสามารถเขียนข้อมูลลงไปใน Bucket ได้

ต้องกล่าวโทษคนเหมือนเช่นเคย

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

บริษัทที่ต้องการหลีกเลี่ยงการโจมตีแบบ GhostWriter นั้นควรอ่านเอกสารดังนี้ให้เข้าใจถึงสิทธิ์การเข้าถึงของ S3 Overview of Managing Access, Introduction to Managing Access Permission to Your Amazon S3 Resource, Managing Access Permission to Your Amazon Resource นอกจากนี้มีเหตุการณ์การรั่วไหลในช่วงหลายเดือนที่ผ่านมาเนื่องจากการตั้งค่า S3 ผิดพลาดดังนี้
  • ข้อมูลของพนักงานกว่าพันคนของธนาคารและหน่วยงานรัฐบาลออสเตรเลียรั่วไหล
  • บริษัทติดตามยานพาหนะแบบอัตโนมัติทำบันทึกข้อมูลกว่าครึ่งล้านรั่วไหลประกอบด้วย ชื่อและรหัสผู้ใช้งาน อีเมล เลขระบุยานพาหนะ เลข IMEI ของอุปกรณ์ GPS และข้อมูลอื่นๆที่อยู่ในอุปกรณ์และข้อมูลลูกค้า
  • บริษัมแม่ของ Wallstreet อย่าง Dow Jones ก็ทำข้อมูลส่วนตัวของลูกค้ากว่า 2.2 ล้านคนรั่วไหล
  • ข้อมูลส่วนตัวของชาวอเมริกันกว่า 198 ล้านคนที่เข้าลงคะแนนช่วงเลือกตั้ง ซึ่งฐานข้อมูลมาจาก 3 บริษัทด้านเหมืองข้อมูลที่เกี่ยวพันกับพรรครีพับริกัล

ที่มา : https://www.bleepingcomputer.com/news/security/misconfigured-amazon-s3-buckets-expose-users-companies-to-stealthy-mitm-attacks/

from:https://www.techtalkthai.com/s3-misconfig-lead-to-ghostwriter/

Google เปิดให้บริการ DNSSEC บน Cloud DNS แล้ว

Google ได้ออกมาประกาศพร้อมให้บริการ DNSSEC บน Google Cloud DNS แล้ว

Credit: Google

 

บริการนี้ยังคงเป็นแบบ Beta โดย Domain Name System Security Extensions หรือ DNSSEC นี้จะช่วยเพิ่มความมั่นคงปลอดภัยให้กับ DNS ด้วยการเปิดให้มีการ Validate ค่า DNS Response ได้ ส่งผลให้สามารถช่วยป้องกันการโจมตี DNS Hijacking และ Man-in-the-Middle ได้นั่นเอง

ผู้ที่สนใจสามารถเข้าไปทำการกำหนดค่าได้ที่ https://cloud.google.com/dns/ หรือศึกษาข้อมูลเพิ่มเติมได้ที่ https://cloud.google.com/dns/dnssec นะครับ

 

ที่มา: http://cloudplatform.googleblog.com/2017/11/DNSSEC-now-available-in-Cloud-DNS.html

from:https://www.techtalkthai.com/google-supports-dnssec-on-cloud-dns/