พบช่องโหว่ใหม่ใน GitHub อาจทำให้ repositories หลายพันรายการเสี่ยงต่อการถูกโจมตีด้วยวิธีการ Repojacking

จากรายงานของ Elad Rapoport นักวิจัยด้านความปลอดภัยของ Checkmarx ที่แชร์กับ The Hacker News ระบุว่า ช่องโหว่นี้อาจทำให้ผู้โจมตีสามารถใช้ประโยชน์จาก race condition ในการดำเนินการสร้าง repository และเปลี่ยนชื่อผู้ใช้ของ GitHub
(more…)

Veeam ประกาศแจ้งเตือนช่องโหว่ใหม่ที่ทำให้ผู้โจมตีสามารถขโมยข้อมูลสำคัญในรูปแบบ cleartext ได้ (CVE-2023-27532) รวมไปถึงปัจจุบันกลุ่ม Horizon3 ได้ปล่อยชุดสาธิตการโจมตี (POC) exploit code ออกมาแล้ว

CVE-2023-27532 (คะแนน CVSS 7.5/10 ระดับความรุนแรงสูง) เป็นช่องโหว่ในคอมโพเนนต์ Veeam Backup & Replication (VBR) ทำให้สามารถหลีกเลี่ยงการยืนยันสิทธิเพื่อเข้าไปใน backup infrastructure และขโมยข้อมูลสำคัญในรูปแบบ cleartext และเรียกใช้งานคำสั่งที่เป็นอันตรายจากระยะไกลได้ (RCE) ด้วยสิทธิ์ SYSTEM ซึ่งส่งผลกระทบกับ VBR ทุกเวอร์ชัน
โดย Veeam ได้ออกอัปเดตเพื่อแก้ไขช่องโหว่สำหรับ VBR เวอร์ชัน11 และ เวอร์ชัน 12 โดยแนะนำให้ผู้ใช้งานรีบทำการอัปเดตโดยด่วน รวมไปถึงยังให้คำแนะนำในกรณีที่ยังไม่สามารถทำการอัปเดตได้ทันที แนะนำให้ปิดการเชื่อมต่อจากภายนอกไปยังพอร์ต TCP 9401
Veeam เป็นบริษัทด้านซอฟต์แวร์สำรองข้อมูลระดับองค์กร โดย Veeam Backup & Replication (VBR) มีลูกค้ามากกว่า 450,000 รายทั่วโลก ซึ่งรวมถึง 82% ของบริษัทที่ติดอันดับ Fortune 500 และ 72% ของ Global 2,000

Horizon3 ปล่อย PoC ออกสู่สาธารณะ
ปัจจุบันทาง Horizon3 ได้ปล่อยตัวอย่างวิธีสาธิตการโจมตี proof-of-concept (PoC) ช่องโหว่ดังกล่าวออกมาแล้ว ซึ่งเป็นในรูปแบบ cross-platform ที่ทำให้สามารถเข้าถึงข้อมูลสำคัญในรูปแบบ cleartext บนฐานข้อมูล โดยใช้ API endpoint ในการโจมตีช่องโหว่ ซึ่งทาง Horizon3 ได้ทำเผยแพร่ PoC นี้บน Github ซึ่งสร้างขึ้นด้วย .NET core และสามารถทำงานบน Linux ได้

โดยช่องโหว่ดังกล่าวมีความอันตรายมาก เนื่องจากหาก Hacker สามารถหลีกเลี่ยงการตรวจสอบสิทธิ และเข้ามาภายในระบบได้แล้ว ก็สามารถที่จะแพร่กระจายไปยังส่วนอื่น ๆ ในระบบของเหยื่อ รวมถึงเรียกใช้งานคำสั่งที่เป็นอันตรายจากระยะไกลได้
นอกจากนี้ทาง Huntress บริษัทวิจัยด้านความปลอดภัย ได้ทำการตรวจสอบเครื่องที่ใช้ VBR จำนวนกว่า 2 ล้าน เครื่องที่เชื่อมต่อกับอินเตอร์เน็ต พบว่ามีเครื่องที่ใช้ VBR มากกว่า 7,500 รายการที่มีความเสี่ยงต่อการถูกโจมตีจากช่องโหว่ CVE-2023-27532
แม้ปัจจุบันยังไม่พบการรายงานโจมตีจากช่องโหว่ดังกล่าว แต่เมื่อมีการเผยแพร่ PoC ออกมาแล้วก็มีความเป็นไปได้ที่ช่องโหว่ดังกล่าวจะถูกใช้ในการโจมตีต่อไป

ที่มา : www.

sekoia.io บริษัทรักษาความปลอดภัยทางไซเบอร์ของฝรั่งเศส พบแคมเปญการแพร่กระจายมัลแวร์ Raccoon และ Vidar Stealers จำนวนมาก โดยการสร้างเว็ปไซต์ปลอมเพื่อแจกจ่ายซอฟต์แวร์เถื่อนที่ถูกฝังมัลแวร์ที่เป็นอันตรายเอาไว้

ขั้นตอนการโจมตี

sekoia.

Okta ผู้ให้บริการด้าน Identity and Access Management (IAM) ได้ออกอีเมลที่ระบุว่า "เป็นความลับ" แจ้งเตือนเหตุการณ์ Security Incident ถึงกรณีที่ Private GitHub ของตนถูกแฮ็กในเดือนธันวาคมที่ผ่านมา โดยทาง BleepingComputer ได้รับการยืนยันว่าเกิดเหตุการณ์นี้เกิดขึ้นจริง

รายละเอียดเหตุการณ์

เมื่อต้นเดือนธันวาถาม GitHub ได้แจ้งเตือน Okta เกี่ยวกับการตรวจพบพฤติกรรมน่าสงสัยเกี่ยวกับการเข้าถึงที่เก็บ Source Code ของ Okta
จากการตรวจสอบ พบว่าเป้าหมายในการโจมตีครั้งนี้คือการคัดลอกโฟลเดอร์ Repository ที่เป็นที่เก็บข้อมูลของ Okta
อย่างไรก็ตาม Okta ยืนยันว่า แม้ผู้โจมตีจะขโมย Source Code ของ Okta ได้สำเร็จ แต่ก็ไม่สามารถเข้าถึงบริการ หรือข้อมูลลูกค้าของ Okta ได้ ดังนั้นลูกค้าที่อยู่ภายใต้มาตรฐาน HIPAA, FedRAMP หรือ DoD ของ Okta จะไม่ได้รับผลกระทบ เนื่องจากบริษัทไม่มีการใส่ข้อมูลของลูกค้าที่เป็นความลับบน Source Code ด้วยเหตุนี้ลูกค้าจึงไม่จำเป็นต้องดำเนินการใด ๆ
ทันทีที่ Okta ทราบเกี่ยวกับพฤติกรรมที่น่าสงสัย จึงได้ทำการจำกัดการเข้าถึงไฟล์ Repository ชั่วคราว นอกจากนี้ยังยกเลิกการ Integration จาก third-party applications ทั้งหมดบน GitHub
จากนั้นได้ตรวจสอบการเข้าถึงทั้งหมดที่ไปยัง Repository บน GitHub รวมถึงทดสอบการเข้าถึงไฟล์ด้วย Environment อื่น ๆ เพื่อให้แน่ใจว่าไม่มีใครสามารถเข้าถึงไฟล์ได้ พร้อมกับชี้แจงว่าเหตุการณ์ครั้งนี้กระทบกับ Okta Workforce Identity Cloud (WIC) code repositories เท่านั้น แต่ไม่กระทบกับ Auth0 Customer Identity Cloud product

สรุปเหตุการณ์ Cybersecurity Incident ของ Okta ในปี 2565

ช่วงปลายเดือนมกราคม 2565 Okta ก็ได้มายอมรับว่ามีข้อมูลรั่วไหล และอาจส่งผลกระทบต่อลูกค้า 2.5% หรือประมาณ 375 องค์กรในเวลานั้น โดยพิจารณาจากฐานลูกค้าของ Okta มากกว่า 15,000 รายในเดือนนี้
เดือนมีนาคม พบว่ากลุ่ม Lapsus$ อ้างว่าได้สิทธิ์เข้าถึง Admin Console และข้อมูลลูกค้าของ Okta โดยการโพสต์ภาพหน้าจอที่มีข้อมูลที่ถูกขโมยบน Telegram
ในเดือนเมษายน พบว่า Okta มีข้อมูลรั่วไหลเป็นระยะเวลา 25 นาที ก่อนที่เหตุการณ์นั้นจะหยุดลง
เดือนกันยายน Auth0 ของ Okta ได้เคยเกิดเหตุการณ์ในลักษณะเดียวกันคือมีการเข้าถึงแหล่งเก็บ Source Code จาก Third Party ภายนอก

ที่มา : bleepingcomputer

GitHub จะกำหนดให้ผู้ใช้งานทุกคนที่เผยแพร่ code บนแพลตฟอร์ม เปิดการใช้งาน Two-factor authentication (2FA) เป็นมาตรการป้องกันเพิ่มเติมบนบัญชีภายในสิ้นปี 2566

ซึ่ง Two-factor authentication จะช่วยเพิ่มความปลอดภัยให้กับบัญชีผู้ใช้ด้วยการเพิ่มขั้นตอนในกระบวนการเข้าสู่ระบบ

สำหรับผู้ใช้งาน GitHub การถูกเข้าถึงบัญชีผู้ใช้งาน สามารถนำไปสู่การเผยแพร่โค้ดที่เป็นอันตรายสำหรับใช้ในการโจมตีในรูปแบบ supply chain attacks ซึ่งขึ้นอยู่กับความนิยมของแต่ละ project โดยบางกรณีอาจมีผลกระทบในวงกว้างได้

การกำหนดให้มีการเปิดใช้งาน 2FA เป็นมาตรการที่จำเป็นสำหรับบัญชี GitHub ทุกบัญชี โดยจะทำให้แพลตฟอร์ม GitHub เป็นพื้นที่ที่ปลอดภัยมากขึ้น ซึ่งจะทำให้ผู้ใช้งานมั่นใจมากขึ้นเกี่ยวกับความปลอดภัยของโค้ดที่ดาวน์โหลดจากแพลตฟอร์ม

เมื่อต้นปีทีผ่านมา GitHub เคยประกาศถึงการตัดสินใจให้ผู้พัฒนา Project ที่มีผลกระทบสูง และมีการดาวน์โหลดมากกว่าหนึ่งล้านครั้งต่อสัปดาห์ต้องมีการเปิดใช้งาน 2FA

ซึ่งการกำหนดให้มีการเปิด 2FA สำหรับผู้ใช้งานทั้งหมดจะครอบคลุมผู้ใช้ประมาณ 83 ล้านคน

การออกข้อกำหนด 2FA

GitHub จะกำหนดให้มีการเปิด 2FA บนบัญชี GitHub ทุกบัญชีตั้งแต่เดือนมีนาคม 2566 โดยในตอนแรกจะผลักดันให้บัญชีผู้ใช้งานที่อยู่ในกลุ่มผู้เผยแพร่ข้อมูลเริ่มดำเนินการก่อน

หลังจากนั้นจะทำการประเมินผลก่อนที่จะขยายไปสู่กลุ่มผู้ใช้งานที่ใหญ่ขึ้น

GitHub กล่าวว่ากลุ่มของผู้ใช้งานที่จะเริ่มดำเนินการจะถูกแบ่งโดยใช้เกณฑ์ดังต่อไปนี้ :

ผู้ใช้ที่เผยแพร่แอป หรือแพ็กเกจ GitHub หรือ OAuth
ผู้ใช้ที่มีการสร้าง code เวอร์ชันใหม่ ๆ
ผู้ใช้ที่เป็นผู้ดูแลองค์กร และองค์กร
ผู้ใช้ที่ contributed code ไปยัง repositories สำคัญ ๆ เช่น npm, OpenSSF, PyPI, หรือ RubyGems
ผู้ใช้ที่ contributed code ไปยัง repositories สาธารณะ และส่วนตัวประมาณสี่ล้านอันดับแรก

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

โดย 28 วันหลังจากเปิดใช้งาน 2FA ผู้ใช้งานจะต้องผ่านการตรวจสอบเพื่อยืนยันการตั้งค่าความปลอดภัยใหม่ รวมถึงจะทำให้ผู้ใช้งานสามารถกำหนดการตั้งค่า 2FA ใหม่ และสามารถกู้คืนรหัสที่หายไปได้

ที่มา : bleepingcomputer

Dropbox ออกมายอมรับเหตุการณ์ข้อมูลรั่วไหล ซึ่งเกิดจากการที่ผู้โจมตีสามารถขโมย code repositories ของบริษัทออกไปกว่า 130 รายการ ภายหลังจากการเข้าถึงบัญชี GitHub โดยใช้ข้อมูลส่วนตัวของพนักงานที่ถูกขโมยจากการโจมตีแบบฟิชชิ่ง

บริษัทพบว่าถูกแฮ็กเมื่อวันที่ 14 ตุลาคม 2565 ที่ผ่านมา เมื่อ GitHub แจ้งว่ามีพฤติกรรมที่น่าสงสัย ซึ่งเกิดขึ้นหนึ่งวันก่อนที่จะมีการส่งการแจ้งเตือน จนถึงปัจจุบัน (1 พฤศจิกายน 2565) จากการตรวจสอบพบว่าข้อมูลที่ผู้โจมตีรายนี้เข้าถึงส่วนใหญ่เป็นคีย์ API ที่ใช้โดยนักพัฒนาของ Dropbox ซึ่งรวมไปถึง source code, ข้อมูลชื่อ และที่อยู่อีเมลกว่า 2000-3000 รายการ ทั้งของพนักงาน Dropbox ของลูกค้าปัจจุบัน และลูกค้าในอดีต ซึ่งปัจจุบัน Dropbox มีผู้ใช้งานที่ลงทะเบียนมากกว่า 700 ล้านคน

การโจมตีเริ่มมาจากอีเมลฟิชชิ่งที่ถูกส่งไปยังพนักงานของ Dropbox หลายคน โดยการใช้อีเมลปลอมที่แอบอ้างเป็นแพลตฟอร์ม CircleCI ซึ่งเมื่อคลิกลิงค์ จะถูก redirect ไปยังหน้า Landing Page ของฟิชชิ่งให้กรอกชื่อผู้ใช้ และรหัสผ่านของ GitHub รวมไปถึงการขอให้กรอก "One Time Password (OTP)” ด้วย

อีเมลฟิชชิ่งที่แอบอ้างเป็น CircleCI

หลังจากสามารถขโมยข้อมูลส่วนตัวของพนักงานของ Dropbox ได้ ผู้โจมตีจึงสามารถเข้าถึง GitHub ของ Dropbox และขโมย code repositories ออกไปกว่า 130 รายการ ซึ่งประกอบไปด้วยข้อมูลสำเนาของไลบรารีของ third-party ที่มีการปรับเปลี่ยนสำหรับการใช้งานของ Dropbox, ผลิตภัณฑ์ต้นแบบที่ใช้ภายใน, เครื่องมือ และ configuration files ที่ใช้โดย Security Team แต่ Dropbox ยืนยันว่า แฮ็กเกอร์ไม่สามารถเข้าถึง core apps หรือ infrastructure หลักได้ รวมไปถึงบัญชี รหัสผ่าน หรือข้อมูลการชําระเงินของลูกค้า เนื่องจากระบบเหล่านั้นมีการรักษาความปลอดภัยที่เข้มงวดมากกว่า

เพื่อตอบสนองต่อเหตุการณ์ที่เกิดขึ้น Dropbox กําลังดําเนินการด้านความปลอดภัยเพิ่มเติม โดยการใช้ WebAuthn และ hardware tokens หรือ biometric factors

ในเดือนกันยายนที่ผ่านมา ผู้ใช้งาน GitHub ทั่วๆ ไป ก็เคยตกเป็นเป้าหมายในการโจมตีในลักษณะคล้ายกัน โดยอีเมลฟิชชิ่งที่แอบอ้างเป็นแพลตฟอร์ม CircleCI และขอให้พวกเขาลงชื่อเข้าใช้บัญชี GitHub เพื่อยอมรับข้อกำหนดของผู้ใช้งาน และการอัปเดตนโยบายความเป็นส่วนตัวเพื่อใช้บริการต่อไป

โดย GitHub ระบุว่ามักจะพบการขโมยข้อมูลออกไปทันทีหลังจากที่บัญชีของผู้ใช้งานถูกเข้าถึงได้ โดยจากการตรวจสอบพบว่าผู้โจมตีส่วนใหญ่จะใช้ VPN หรือบริการ Proxy เพื่อทำให้ติดตามได้ยากขึ้น

ที่มา : bleepingcomputer.

บัญชี GitHub ถูกแฮ็กโดยผู้ไม่หวังดีที่แอบอ้างเป็นแพลตฟอร์ม CircleCI DevOps ผ่านทางแคมเปญฟิชชิ่งที่กำหนดเป้าหมายไปยังผู้ใช้งาน GitHub เพื่อขโมย credentials และ two-factor authentication (2FA)

ลักษณะการโจมตีของผู้โจมตี

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

โดยเป้าหมายของผู้โจมตีเพื่อขโมยข้อมูล credentials ของบัญชี GitHub และ two-factor authentication (2FA)
หลังจากผู้โจมตีสามารถขโมย credentials ได้สำเร็จ จะทำการสร้าง personal access tokens (PATs) เพื่ออนุญาตโปรแกรม OAuth และเพิ่มคีย์ SSH ให้สามารถได้รับการเข้าถึงบัญชีโดยไม่ได้รับอนุญาต

โดเมนจริงของ CircleCI คือ [circleci.

พบช่องโหว่ Zero-day ในแอปพลิเคชัน 7-zip โดยช่องโหว่ที่พบนี้สามารถยกระดับสิทธิ์ผู้โจมตีให้เป็นผู้ดูแลระบบได้ ช่องโหว่นี้ถูกค้นพบโดยผู้ใช้ GitHub ที่ชื่อว่า Kagancapar โดยมีหมายเลข CVE-2022-29072

7-zip เป็นแอปพลิเคชันที่สามารถใช้งานได้หลายแพลตฟอร์ม แต่ช่องโหว่นี้ส่งผลกระทบกับ Windows โดยตรง เนื่องการโจมตีต้องอาศัย Windows help application ที่ชื่อว่า hh.

Spring ได้ออกแพตซ์อัปเดตเร่งด่วนเพื่อแก้ไขช่องโหว่ Zero-day remote code execution ของ 'Spring4Shell' ซึ่งก่อนหน้านี้มีข้อมูลรายละเอียดของช่องโหว่ และโค้ดที่ใช้การโจมตีถูกปล่อยออกมา ก่อนที่จะมีแพตช์อัปเดตเพื่อแก้ไขช่องโหว่ดังกล่าว

เมื่อวานนี้ (30 มีนาคม 2022) มีการพบ exploit code ที่ใช้สำหรับโจมตีช่องโหว่ remote code execution ใน Spring Framework ที่มีชื่อว่า 'Spring4Shell' มีการเผยแพร่อยู่บน GitHub และได้ถูกลบออกไปแล้ว อย่างไรก็ตามข้อมูลได้ถูกแชร์ออกไปอย่างรวดเร็ว และได้มีการทดสอบโดยนักวิจัยด้านความปลอดภัย ซึ่งยืนยันว่าสามารถใช้ในการโจมตีได้จริง

Spring ได้ออกคำแนะนำด้านความปลอดภัยโดยแจ้งว่าช่องโหว่นี้ (CVE-2022-22965) จะส่งผลกระทบต่อแอปพลิเคชัน Spring MVC และ Spring WebFlux ใน JDK 9

การโจมตีช่องโหว่ดังกล่าวต้องใช้ Apache Tomcat, แอปพลิเคชันแพ็คเกจ WAR และ "spring-webmvc หรือ spring-webflux" dependencies

ช่องโหว่ดังกล่าวส่งผลกระทบกับแอปพลิเคชัน Spring MVC และ Spring WebFlux ที่ทำงานบน JDK 9+ ซึ่งการโจมตีจะสำเร็จได้ก็ต่อเมื่อ แอปพลิเคชันที่ทำงานบน Tomcat ที่ถูกติดตั้งในรูปแบบ WAR

หากแอปพลิเคชันถูกติดตั้งเป็น Jar เป็นค่าเริ่มต้น จะไม่มีความเสี่ยงต่อการถูกโจมตี อย่างไรก็ตามช่องโหว่ดังกล่าวมีรายละเอียดที่ค่อนข้างกว้าง และอาจมีวิธีอื่นในการใช้ประโยชน์จากช่องโหว่ดังกล่าว (more…)

Omer Gil และทีม พบช่องโหว่ซึ่งเป็นส่วนหนึ่งของ DevOps ตาม Blog และได้แจ้งกับทาง Information Security Media Group ว่าต้องมีการตรวจสอบกลไกในการตรวจสอบบน GitHub และเนื่องจาก GitHub Actions เป็นส่วนที่มีการติดตั้งเป็นค่า default เบื้องต้นทำให้มีผลต่อองค์กรที่มีการใช้งานทุกที่

GitHub เป็นแพลตฟอร์มในการพัฒนาซอฟต์แวร์ที่ใช้ควบคุมการดำเนินการแก้ไข การตรวจสอบการดำเนินการต่างๆใน Codeโปรแกรมต่างๆที่ทางผู้พัฒนาโปรแกรมได้ทำการสร้างขึ้น โดย GitHub Action คือการส่งต่อข้อมูลที่ทางผู้พัฒนาได้มีการแก้ไข สร้าง workflows เพื่อทำการส่งต่อไปยัง production

เมื่อ workflows ทำงานจะทำการสร้าง GITHUB_TOKEN มาใช้เพื่อทำการตรวจสอบสิทธิ์ โดยสิทธิ์ต่างๆจะถูกตั้งค่าตามแต่ละองค์กร เช่น สิทธิ์ในการ อ่าน เขียน เข้าถึงขอบเขตของข้อมูลบางส่วน เนื้อหา แพ็คเกจที่สามารถร้องขอได้ โดยผู้ใช้งานที่มีสิทธิ์ในการเขียน สามารถปรับเปลี่ยนการอนุญาตในการเข้าถึงไฟล์หรืออนุญาตการ merge หากผู้ไม่หวังดีสามารถเข้าถึง Account ที่มีสิทธิ์ในการแก้ไขได้ จะสามารถส่ง Code ที่เป็นอันตรายไปยังระบบงานต่างๆที่สามารถเข้าถึงได้ทั้งหมด

โดย GITHUB_TOKEN จะทำงานควบคู่กับ PR (การตรวจสอบทบทวนสิ่งที่มีการขอ merge request) User สามารถทบทวนสิ่งที่ผู้ใช้งานบางคนทำการเปลี่ยนแปลงแก้ไข ก่อนที่จะส่งไปยังระบบงาน production เมื่อ PR ถูกสร้างขึ้นมาจะไม่สามารถ merge ข้อมูลรวมกันได้เนื่องจากจะต้องมีการอนุมัติเสียก่อน แต่ในการโจมตีนี้ workflows จะทำงานทันทีเมื่อมีการอนุญาตจาก PR โดย github-actions bot

โดยทางนักวิจัยได้รายงานเหตุการณ์ ดังกล่าวกับทาง GitHub และบอกถึงผู้ใช้งาน GitHub ให้ดำเนินการปิด GitHub Action หากไม่ได้ใช้งาน และเพิ่มการตรวจสอบสิทธิ์ในการส่งต่อ Code ให้มากขึ้นโดยการตรวจสอบมากกว่า 2 ครั้งขึ้นไปจนกว่า GitHub จะมีการแก้ไขช่องโหว่ดังกล่าว

ที่มา: bankinfosecurity.