OpenSSL แจ้งเตือนช่องโหว่ระดับร้ายแรงสูง โจมตีแบบ Denial of Service ได้

โครงการ OpenSSL ประกาศเวอร์ชันใหม่ของซอฟต์แวร์ OpenSSL พร้อมกับแพตช์ด้านความปลอดภัยสำหรับช่องโหว่ที่ถูกแจ้งโดย David Benjamin จาก Google ช่องโหว่ถูกโจมตีและทำให้ระบบที่ใช้งานตกอยู่ในเงื่อนไข Denial of Service (DoS) ได้

ช่องโหว่ดังกล่าวเกิดจากปัญหา null pointer derefence ในการตรวจสอบข้อมูลในใบรับรอง X.509 โดยแฮกเกอร์สามารถสร้างใบรับรองแบบพิเศษ จากนั้นหลอกให้เหยื่อซึ่งใช้ซอฟต์แวร์ OpenSSL ในรุ่นที่มีช่องโหว่ทำการเข้าถึงและตรวจสอบ เหยื่อจะถูกโจมตีและเจอข้อผิดพลาด DoS ได้

ช่องโหว่นี้ส่งผลกระทบกับ OpenSSL ในรุ่น 1.1.1 และ 1.0.2 ผู้ใช้งานควรทำการอัปเกรดเป็น OpenSSL 1.1.1i โดยด่วน

ที่มา: securityweek

OpenSSL Project fixed high-severity CVE-2020-1967 DoS issue in OpenSSL

OpenSSL แก้ไขช่องโหว่ CVE-2020-1967 ที่เป็นช่องโหว่ในการโจมตี DoS ใน OpenSSL

โครงการ OpenSSL ได้เปิดตัวแพตช์ความปลอดภัยสำหรับ OpenSSL ที่ทำการเเก้ไขช่องโหว่ที่มีความรุนแรงสูงถูกติดตามเป็น CVE-2020-1967 ทำให้ผู้โจมตีสามารถโจมตีแบบปฏิเสธการให้บริการ (DoS) โดยช่องโหว่นี้ถูกค้นพบโดย Bernd Edlinger และได้รายงานต่อ OpenSSL เมื่อวันที่ 7 เมษายน 2020 ที่ผ่านมา

ช่องโหว่ CVE-2020-1967 ช่องโหว่เกิดจากปัญหาการเรียกใช้ฟังก์ชัน SSL_check_chain () ในระหว่างการทำ Handshake กับ TLS 1.3 ที่เกิดการล้มเหลวจึงทำให้ NULL pointer จัดการกับ extension ที่ชื่อ Signature_algorithms_cert บน TLS extension ไม่ถูกต้อง ผู้โจมตีสามารถใช้ประโยชน์จากความผิดพลาดที่เกิดขึ้นได้โดยใช้ peer ที่ออกแบบมาเป็นพิเศษทำการโจมตี ซึ่งอาจจะทำให้เกิดการปฏิเสธการให้บริการ (DoS) บนเซิร์ฟเวอร์หรือแอปพลิเคชันไคลเอนต์ที่ OpenSSL กำลังทำงานอยู่

ช่องโหว่นี้ส่งผลกระทบต่อ OpenSSL เวอร์ชั่น 1.1.1d, 1.1.1e และ 1.1.1f

การอัพเดตแพตช์
ปัญหาจากช่องโหว่ได้รับการเเก้ไขใน OpenSSL เวอร์ชั่น 1.1.1g ผุ้ใช้งานควรทำการอัพเดตแพตช์เพื่อป้องกันการโจมตี

ที่มา : securityaffairs

OpenSSL Releases Security Updates

OpenSSL ออกรุ่นย่อยให้กับเวอร์ชัน 1.1.0 และ 1.0.2 เพื่อแก้ช่องโหว่ด้านความปลอดภัย 3 รายการ โดยมี 2 ช่องโหว่ที่มีความเสี่ยงอยู่ในระดับกลางและอีก 1 ช่องโหว่อยู่ในระดับต่ำ

สำหรับช่องโหว่ระดับกลาง 2 ช่องโหว่นั้น ช่องโหว่หนึ่งส่งผลให้ผู้โจมตีสามารถทำ DoS โดยการสร้างใบรับรองในฟอร์แมต ASN.1 ในรูปแบบที่ผิดปกติได้ ส่วนอีกช่องโหว่หนึ่งเป็นช่องโหว่เฉพาะในซีพียู HP-UX PA-RISC ที่อาจทำให้เกิดการจำลองข้อมูลที่ผ่านการพิสูจน์ตัวตนซึ่งอาจกระทบต่อคุณสมบัติด้านปลอดภัยได้ ส่วนช่องโหว่ในระดับต่ำที่ถูกระบุว่ามีการแพตช์แล้วนั้นเป็นช่องโหว่ overflow ที่ความเสี่ยงและโอกาสเกิดขึ้นต่ำ

Recommendation OpenSSL ในเวอร์ชัน 1.1.0 ควรถูกอัปเกรดให้อยู่ในรุ่น 1.1.0h ส่วนในเวอร์ชัน 1.0.2 ควรอัปเกรดให้อยู่ในรุ่น 1.0.2o

ที่มา: us-cert

OpenSSL Security Advisory

OpenSSL 1.1.0 และ 1.2.0 Conclusion แพตช์ด้านความปลอดภัย OpenSSL ประจำเดือนธันวาคม 2017 ไม่ค่อยร้ายแรงเท่าไหร่แต่ก็แนะนำให้อัปเดต

โครงการ OpenSSL ประกาศแพตช์ด้านความปลอดภัยประจำเดือนธันวาคม 2017 เมื่อวันพฤหัสที่ผ่านมาโดยในรอบนี้นั้นประกอบไปด้วยแพตช์สำหรับ 2 ช่องโหว่ด้วยกัน

ช่องโหว่แรกรหัส CVE-2017-3737 เป็นช่องโหว่ระดับความร้ายแรงปานกลางที่ส่งผลให้แม้ว่า SSL/TLS connection จะอยู่ในสถานะล้มเหลวในการเชื่อมต่อไปแล้ว โปรแกรมก็อาจสามารถส่งข้อมูลออกไปได้โดยไม่มีการเข้ารหัสที่เหมาะสม ช่องโหว่นี้ไม่กระทบ OpenSSL 1.1.0 ส่วนผู้ใช้งานที่ใช้งาน 1.0.2 อยู่แนะนำให้อัปเดตไปที่ 1.0.2n

ช่องโหว่ที่สอง CVE-2017-3738 เป็นช่องโหว่ระดับความร้ายแรงต่ำซึ่งเกิดจากการ overflow ในอัลกอริธึมคำนวณจำนวนเฉพาะซึ่งจะเกิดขึ้นบนโปรเซสเซอร์ที่รองรับ AVX2 เท่านั้น ช่องโหว่นี้กระทบ 1.1.0 แต่เนื่องจากความรุนแรงที่ต่ำ แพตช์จะถูกปล่อยมาใน 1.1.0h ซึ่งเป็นรุ่นในอนาคตแทน ส่วนผู้ใช้งานที่ใช้งาน 1.0.2 อยู่แนะนำให้อัปเดตไปที่ 1.0.2n

ที่มา : openssl

OpenSSL Security Advisory

แพตช์ล่าสุดสำหรับ OpenSSL มาแล้ว

โครงการ OpenSSL ได้มีการประกาศแพตช์ด้านความปลอดภัยล่าสุดสำหรับซอฟต์แวร์ OpenSSL ในวันที่ 2 พฤศจิกายนที่ผ่านมา โดยแพตช์ในรอบนี้นั้นปิดช่องโหว่สองช่องโหว่ที่ระดับความรุนแรงปานกลางและต่ำ โดยมีรายละเอียดของช่องโหว่ดังนี้

ช่องโหว่แรกรหัส CVE-2017-3736 เป็นช่องโหว่ในกระบวนการคำนวณหาค่าตัวเลขที่มีขนาดใหญ่อย่างรวดเร็วซึ่งถูกคิดค้นโดย Peter Montgomery ช่องโหว่นี้ถูกรายงานว่าไม่กระทบต่อกระบวนการสร้างคีย์ในอัลกอริธึมที่อยู่บนพื้นฐานของ Elliptic-curve แต่ส่งผลกระทบ "ในระดับที่น้อยมากและเป็นไปได้ยากมากๆ ที่จะโจมตี" กับ RSA และ DSA และจะส่งผลกระทบในระบบที่ใช้โปรเซสเซอร์ที่มีส่วนเสริม BMI1, BMI2 และ ADX อาทิ Intel Broadwell และ AMD Ryzen เท่านั้น

ช่องโหว่ที่สองรหัส CVE-2017-3735 เป็นช่องโหว่ one-byte buffer overread หากมีการกำหนดค่าในฟิลด์ IPAddressFamily ของ certificate แบบ X.509 ที่ไม่เหมาะสม ซึ่งอาจส่งผลกระทบต่อการแสดงข้อมูลเมื่อมีการเรียก certificate มาดูได้

ทั้งสองช่องโหว่สามารถแพตช์ได้ผ่านการอัพเดตซอฟต์แวร์ โดยสำหรับผู้ใช้งานที่ใช้รุ่น 1.1.0 ให้ทำการอัพดตไปเป็น 1.1.0g และสำหรับผู้ใช้งานที่ใช้รุ่น 1.0.2 ให้ทำการอัพเดตไปเป็น 1.0.2m

ที่มา openssl

Securing Network Time

สรุปการตรวจสอบด้านความปลอดภัยของ ntpd, NTPSec และ Chrony จาก Core Infrastructure Initiative

Core Infrastructure Initiative (CII) เป็นโครงการภายใต้ Linux Foundation ซึ่งมีหน้าที่ในการหาทุนและช่วยสนับสนุนโครงการซอฟต์แวร์แบบโอเพนซอร์สหลายโครงการที่มีความสำคัญสูง อาทิ OpenSSL, OpenSSH รวมไปถึง ntpd และ NTPsec ล่าสุด CII ร่วมกับ Mozilla ได้ร่วมกันสนับสนุนทุนเพื่อตรวจสอบซอร์สโค้ดของโครงการซอฟต์แวร์ 3 โครงการที่อิมพลีเมนต์การทำงานของโปรโตคอล NTP ได้แก่ ntpd, NTPSec และ Chrony โดยการตรวจสอบทั้งหมดนั้นถูกดำเนินการโดยบริษัทด้านความปลอดภัย Cure53

สำหรับความปลอดภัยของโปรแกรม ntpd นั้น Cure53 ได้ทำการตรวจสอบ ntpd ในรุ่น 4.2.8p10 ซึ่งมีการเผยแพร่ในเดือนมีนาคม 2017 ด้วยลักษณะของโครงการ ntpd ซึ่งเป็นโครงการซอฟต์แวร์แรกที่อิมพลีเมนตร์การทำงานของโปรโตคอล NTP และมีประวัติการพัฒนายาวนานมากว่า 25 ปี การตรวจสอบด้านความปลอดภัยจึงมีการตรวจพบช่องโหว่กว่า 12 รายการ ( 1 Critical, 2 High, 1 Medium และ 8 Low)

ในขณะเดียวกันโครงการ NTPSec ที่มีการแยกพัฒนาต่อจาก ntpd เพื่อลดความซับซ้อนและแก้ไขปัญหาด้านความปลอดภัยถูกตรวจพบว่ามีช่องโหว่ 7 ช่องโหว่ (3 High, 1 Medium และ 3 Low ) เมื่อเปรียบเทียบกับความก้าวหน้าของโครงการ NTPsec ซึ่งในเวลานี้ยังไม่มีการปล่อยเวอร์ชันเต็ม (1.0) ออกมา NTPSec ยังต้องมีการพัฒนาอีกพอสมควรเพื่อให้สามารถปล่อยซอฟต์แวร์ในรุ่นที่มีความสมบูรณ์มากที่สุดออกมาได้

สำหรับโครงการ Chrony ซึ่งเป็นโครงการที่ไม่ได้มีการพัฒนาต่อมาจาก ntpd เดิมนั้น มีเพียง 2 ช่องโหว่ที่ถูกตรวจพบ โดยทั้งสองช่องโหว่นั้นมีความรุนแรงอยู่ในระดับต่ำ (Low) รายงานจาก Cure53 ยังระบุเพิ่มเติมว่า Chrony เป็นซอฟต์แวร์ที่แข็งแกร่งมากและยังแสดงให้เห็นว่านักพัฒนามีการคำนึงถึงเรื่องความปลอดภัยอยู่ตลอด ซึ่งโดยสรุปแล้ว Chrony เป็นซอฟต์แวร์ที่สมควรได้รับความน่าเชื่อถือในการใช้งาน

ข้อมูลการตรวจสอบพร้อมทั้งรายงานของ Cure53 ฉบับเต็มนั้นสามารถตรวจสอบได้จากแหล่งที่มา

ที่มา : Coreinfrastructure

It took DEF CON hackers minutes to pwn these US voting machines

ในปีนี้ที่งาน DEF CON hacking meeting ในลาสเวกัสมีการนำกล่องสำหรับลงคะแนนเสียงในการเลือกตั้งจำนวน 30 กล่องซึ่งมีการใช้งานครั้งล่าสุดในการเลือกตั้งประธานาธิบดีสหรัฐฯ มาทำการทดสอบด้านความปลอดภัย

ภายในเวลาไม่ถึง 90 นาทีจุดอ่อนแรกในระบบก็เริ่มปรากฏขึ้นซึ่งเผยให้เห็นถึงระดับความปลอดภัยที่น้อยมาก มีการใช้ซอฟต์แวร์ที่ล้าสมัยและเต็มไปด้วยช่องโหว่ อาทิ OpenSSL, Windows XP และ CE รุ่นที่ไม่ได้รับการอัพเดต อีกทั้งยังมีพอร์ตทางกายภาพที่อาจใช้ในการติดตั้งซอฟต์แวร์ที่เป็นอันตรายเพื่อแทรกแซงผลคะแนนเลือกตั้ง การแก้ปัญหาด้วยการมีคนเฝ้าระวังที่จุดเลือกตั้งก็ไม่ได้ช่วยลดความเสี่ยง เพราะช่องโหว่อีกจุดหนึ่งนั้นสามารถทำการเจาะระบบกล่องสำหรับลงคะแนนเสียงในการเลือกตั้งผ่านสัญญาณ Wifi ได้ นักวิจัยด้านความปลอดภัย Caross Schurmann ยังแสดงการใช้ช่องโหว่รหัส MS03-026 ใน Windows XPเพื่อเข้าถึงเครื่องจากแล็ปท็อปของเขาโดยใช้ RDP (Remote Desktop Connection)

นอกจากนี้เครื่องเลือกตั้งไม่สามารถลบข้อมูลผู้ลงคะแนนได้อย่างสมบูรณ์ ยังมีเร็กคอร์ดส่วนตัวของผู้มีสิทธิเลือกตั้งประมาณ 650,000 รายค้างอยู่ในเครื่อง และแฮกเกอร์ยังสามารถหารหัสผ่านสำหรับผู้ดูแลระบบผ่านทาง Google ด้วย

ที่มา : theregister

ช่องโหว่ DROWN เปิดทางให้แฮกเกอร์ถอดรหัสการเชื่อมต่อ TLS ในเซิร์ฟเวอร์ที่รับ SSLv2

ทีมวิจัยรายงานการโจมตี DROWN ที่สามารถถอดรหัสการเชื่อมต่อ TLS รุ่นใหม่ๆ (ทดสอบใน TLS 1.2) ได้สำเร็จ โดยกระบวนการนี้มีแม้จะอันตรายมากแต่ก็มีเงื่อนไขหลายอย่าง ได้แก่

แฮกเกอร์ต้องดักฟังการเชื่อมต่อ TLS ที่จะโจมตีไว้ล่วงหน้า ประมาณ 1,000 การเชื่อมต่อ (ไม่นับการใช้การเชื่อมต่อ TLS ซ้ำ)
เซิร์ฟเวอร์ต้องรองรับ SSLv2 โดยใช้ใบรับรองใบเดียวกับที่ใช้ TLS
แฮกเกอร์ต้องสามารถเชื่อมต่อ SSLv2 ได้จำนวนมากๆ ประมาณ 40,000 ครั้ง
เซิร์ฟเวอร์ SSLv2 จะต้องรองรับการเชื่อมต่อที่อ่อนแอ (export grade)

แฮกเกอร์มีพลังประมวลผลเหลือเฟือ สามารถคำนวณหากุญแจความซับซ้อนระดับ 2^50 ได้ ค่าใช้จ่ายใน EC2 ประมาณ 440 ดอลลาร์

ทีมวิจัยอาศัยช่องโหว่ padding oracle ของ SSLv2 เพื่อคำนวณหาค่าที่จำเป็นจากการเชื่อมต่อ SSLv2 จำนวนมาก แล้วใช้ค่าเหล่านั้นมาถอดรหัสการเชื่อมต่อ TLS อันใดอันหนึ่งจากที่ดักฟังมา 1,000 การเชื่อมต่อได้ หากเป็นการเชื่อมต่อเว็บ แฮกเกอร์ต้องการถอดรหัสเพียงการเชื่อมต่อเดียวเพื่อจะโมย cookie ไปสวมรอยบัญชี

SSLv2 ไม่ได้รับความนิยมนัก โดยเฉพาะเว็บเซิร์ฟเวอร์ แต่เซิร์ฟเวอร์จำนวนมากก็ใช้ใบรับรองเดียวกันระหว่างเว็บเซิร์ฟเวอร์กับบริการอื่นๆ ที่อาจจะคอนฟิกไว้หละหลวมกว่าเช่นเมลเซิร์ฟเวอร์ ทีมงานพบว่ามีเว็บเซิร์ฟเวอร์ที่ยังรองรับ SSLv2 อยู่ 16% แต่มีการใช้ใบรับรองซ้ำในบริการอื่นที่รองรับ SSLv2 อยู่อีก 17% ทำให้เซิร์ฟเวอร์ที่มีความเสี่ยงรวมเป็น 33%

ทางแก้ที่ตรงไปตรงมาคือการปิดการรองรับ SSLv2 ทุกบริการเสีย ทางด้าน OpenSSL ออกแพตช์มาแล้วในรุ่น 1.0.2g และ 1.0.1s โดยปิดการทำงานการเข้ารหัสในกลุ่ม EXPORT และ LOW ออกทั้งหมดเป็นค่าเริ่มต้น

ช่องโหว่นี้มีคะแนน CVSS ระดับ 5.8 จัดอยู่ในช่องโหว่ระดับสำคัญ ทาง Red Hat นั้นกระทบตั้งแต่ RHEL 5/6/7 ส่วน IIS ของไมโครซอฟท์ระบุว่าเวอร์ชั่นที่ซัพพอร์ตอยู่ตอนนี้ปิด SSLv2 ไปทั้งหมดแล้ว

ที่มา : blognone

OpenSSL Patches Critical Certificate Validation Vulnerability

OpenSSL Project ได้ทำการปล่อยแพทช์ Security Update ใหม่หมายเลข CVE-2015-1793 สำหรับผู้ที่ใช้งาน OpenSSL เพื่ออุดช่องโหว่ความรุนแรงสูงที่ช่วยให้ผู้ไม่ประสงค์ดีสามารถปลอมแปลง Certificate ได้ โดยแฮกเกอร์สามารถเปลี่ยน Certificate ของตนจาก Untrusted Certificate กลายเป็น Trusted Certificate ซึ่งอาจเสี่ยงถูกโจมตีแบบ Man-in-the-middle

ช่องโหว่การปลอม Certificate นี้พบใน OpenSSL เวอร์ชัน 1.0.1 และ 1.0.2 ที่เปิดให้ใช้งานหลังเดือนมิถุนายน 2015 ซึ่งได้แก่ เวอร์ชัน 1.0.1n, 1.0.1o, 1.0.2b และ 1.0.2c สำหรับเวอร์ชัน 0.9.8 และ 1.0.0 นั้นไม่ได้รับผลกระทบต่อช่องโหว่ดังกล่าวแต่อย่างใด อย่างไรก็ตาม ทั้ง 2 เวอร์ชันนี้จะถูกปลดระวาง (End of Support) ในวันที่ 31 ธันวาคม 2015 นี้ จึงแนะนำให้ผู้ใช้งานเตรียมแผนอัพเกรดเป็นเวอร์ชันใหม่โดยเร็ว

OpenSSL Project แนะนำให้ผู้ที่ใช้งานเวอร์ชัน 1.0.1 อัพเกรดเป็น 1.0.1p และผู้ที่ใช้งานเวอร์ชัน 1.0.2 อัพเกรดเป็น 1.0.2d

ที่มา : threat post

OpenSSL patches Logjam vulnerability

OpenSSL ออกแพตช์ความปลอดภัยชุดใหม่ อุดช่องโหว่ระดับปานกลางและระดับต่ำหลายตัว แต่ที่สำคัญที่สุดคงเป็นการช่องโหว่ Logjam ที่ทำให้ Client ถูกหลอกว่ากำลังเชื่อมต่อแบบปกติ ทั้งที่เป็นการเชื่อมต่อแบบ DHE_EXPORT ที่ความปลอดภัยต่ำ

แนวทางแก้ปัญหาคือ โค้ดฝั่ง Client ของ OpenSSL จะไม่ยอมรับ การเชื่อมต่อแบบ DH ที่ 512 บิตอีกต่อไป โดยตอนนี้จะยอมรับที่ 768 เป็นขั้นต่ำสุด และเตรียมจะปรับเป็น 1024 บิตในอนาคต

ที่มา :  itnews