เรื่องราวที่บังเอิญพบช่องโหว่ Debian weak keys
(hezmatt.org)- งานแก้คอขวดการล็อกอิน SSH ของ GitHub ในปี 2008 กลายเป็นจุดเริ่มต้นที่เผยให้เห็น การชนกันที่ผิดปกติ ซึ่งผู้ใช้ต่างคนกันมี fingerprint ของ SSH key เหมือนกัน
- GitHub แพตช์ OpenSSH ให้ค้นหา fingerprint ของ key จาก MySQL เพื่อหลีกเลี่ยงปัญหา การค้นหาแบบเชิงเส้น ในไฟล์
authorized_keysที่ใหญ่ขึ้นเรื่อย ๆ - หลังปล่อยแพตช์ เกิดปัญหาที่สามารถเข้าถึง repository ของผู้ใช้อื่นผ่าน SSH ได้ แต่การชนกันของ fingerprint ที่เกิดซ้ำ ๆ นั้นยากจะมองว่าเป็นแค่บั๊กของแพตช์
- เมื่อ DSA-1571-1 ถูกเปิดเผยเมื่อวันที่ 13 พฤษภาคม 2008 จึงยืนยันได้ว่า Debian OpenSSL ได้สร้าง private key ที่คาดเดาได้ มาราว 18 เดือน และจำนวน key ที่เป็นไปได้ลดลงเหลือเพียงมากกว่า 32,000 เล็กน้อยต่อผู้ใช้
- เหตุการณ์ด้านความปลอดภัยครั้งใหญ่มักเริ่มจากสัญญาณเล็ก ๆ ว่า “แปลก” และ เวลาและความสามารถ ในการตามร่องรอยนั้นไปจนสุดต่างหากที่สร้างความแตกต่างจริง ๆ
เหตุการณ์ที่เริ่มจากคอขวดการล็อกอิน SSH ของ GitHub
- ในเดือนมีนาคม 2008 ผู้เขียนซึ่งทำงานอยู่ที่ Engine Yard ได้เข้าไปช่วยแก้ปัญหาประสิทธิภาพการล็อกอิน SSH ของ GitHub ซึ่งเป็นลูกค้าของบริษัทโฮสติ้งที่เน้น Rails
- GitHub ให้บริการเข้าถึง Git repository ด้วยการเชื่อมต่อ SSH ไปยัง
git@github.comแล้วใช้การยืนยันตัวตนด้วย public key - ตอนนั้นการจัดการ key อาศัยวิธีทั่วไปคือไฟล์
~/.ssh/authorized_keys- เมื่อ SSH ได้รับคำขอยืนยันตัวตนด้วย public key จะเปิดไฟล์
authorized_keysแล้ว ค้นหาแบบเชิงเส้น เพื่อหารายการที่ตรงกับ key ที่ส่งมา - สำหรับบัญชีทั่วไปที่มี key เพียงไม่กี่รายการ ปัญหานี้ไม่ใหญ่นัก แต่สำหรับ GitHub ที่กำลังเติบโตอย่างรวดเร็ว SSH key ทั้งหมดถูกสะสมอยู่ในไฟล์ขนาดใหญ่ไฟล์เดียว ทำให้เวลาในการล็อกอินช้าลงอย่างเห็นได้ชัด
- เมื่อ SSH ได้รับคำขอยืนยันตัวตนด้วย public key จะเปิดไฟล์
แพตช์ OpenSSH และการค้นหา key ใน MySQL
- หลังพิจารณาทางออกหลายแบบ ทีม GitHub และผู้เขียนเลือกแพตช์ OpenSSH ให้ค้นหา key จาก ฐานข้อมูล MySQL โดยอิงจาก fingerprint ของ key
- การตัดสินใจนี้ไม่ใช่การเปลี่ยนแปลงที่ทำได้เบา ๆ
- การแก้ไข OpenSSH หากผิดพลาดอาจส่งผลร้ายแรงต่อความปลอดภัย
- แต่เพราะทางเลือกอื่นแย่กว่า จึงประเมินว่าเป็นแนวทางที่ “แย่น้อยที่สุด”
- งานเปลี่ยนแปลงส่วนใหญ่หมดไปกับการตรวจสอบว่าไม่ได้ทำให้ความปลอดภัยเสียหาย
- หลังปล่อยใช้งานช่วงต้นเดือนเมษายน 2008 การล็อกอิน SSH ก็เร็วขึ้น และดูเหมือนว่าจะไม่ต้องกังวลกับปัญหาเดิมไปอีกระยะหนึ่ง
อาการที่ดูเหมือนเป็นไปไม่ได้: fingerprint ของ key ซ้ำกัน
- ช่วงต้นเดือนพฤษภาคม 2008 ทีม GitHub ส่งข้อความมาว่าผู้ใช้ GitHub บางรายสามารถเข้าถึง repository ของผู้ใช้อื่นผ่าน SSH ได้
- เนื่องจากปัญหาเกี่ยวข้องโดยตรงกับการยืนยันตัวตนด้วย SSH key และเพิ่งมีการปล่อยแพตช์ OpenSSH ไปไม่นาน โค้ดที่ผู้เขียนเขียนจึงกลายเป็นผู้ต้องสงสัยอันดับแรก
- หลังดีบักจึงยืนยันได้ว่าผู้ใช้สองคนที่ต่างกันมี fingerprint ของ key เหมือนกัน
- หากไม่ใช่กรณีที่ผู้ใช้แชร์ key กันเอง เรื่องนี้แทบจะไม่ควรเกิดขึ้น
- ผู้ใช้ที่ได้รับผลกระทบตอบว่าพวกเขาไม่รู้จักกัน และไม่เคยเปิดเผย key ของตน
- ต่อมาพบ fingerprint ของ key เหมือนกันในผู้ใช้อีกคู่หนึ่ง และ fingerprint นั้นเป็นค่าคนละค่ากับกรณีก่อนหน้า
- สถานการณ์จึงยากจะอธิบายว่าเป็นเหตุบังเอิญครั้งเดียวหรือบั๊กของเว็บแอปพลิเคชันเท่านั้น
- หลังยืนยันได้เพียงพอว่าแพตช์ OpenSSH ไม่ใช่สาเหตุ การมีส่วนร่วมโดยตรงของผู้เขียนก็ลดลง
- ผู้เขียนไม่ได้เป็นพนักงาน GitHub และยังต้องดูแลงานซัพพอร์ตลูกค้ารายอื่นของ Engine Yard ด้วย
- ทีม GitHub ยังคงตรวจสอบกับผู้ใช้ต่อไป และพบจุดร่วมว่าพวกเขาสร้าง SSH key บนระบบ Debian หรือ Ubuntu
สาเหตุที่เปิดเผยจากช่องโหว่ Debian OpenSSL
- เมื่อ DSA-1571-1 ถูกเผยแพร่เมื่อวันที่ 13 พฤษภาคม 2008 สถานการณ์ก็ชัดเจนขึ้น
- แพ็กเกจ Debian OpenSSL ได้สร้าง private key ที่คาดเดาได้ อยู่ประมาณ 18 เดือน
- สาเหตุเกิดจากระหว่างการจัดระเบียบโค้ดสร้างเลขสุ่มของ OpenSSL ผู้ดูแล Debian ได้ลดพื้นที่ของ key ที่สามารถสร้างได้ลงอย่างมากโดยไม่ตั้งใจ
- จำนวน key ที่เป็นไปได้ที่ผู้ใช้หนึ่งรายสามารถสร้างได้ ลดจาก “จำนวนมหาศาล” เหลือ มากกว่า 32,000 เล็กน้อย
- เมื่อมีผู้ใช้จำนวนมากสมัคร GitHub บางส่วนอาจสร้าง key ใหม่แยกต่างหากตามแนวทางปฏิบัติที่แนะนำ และผลลัพธ์ก็คือเกิดการชนกันได้
- การเปิดเผยครั้งนี้กลายเป็นหลักฐานชี้ขาดว่าแพตช์ OpenSSH ของผู้เขียนไม่ใช่สาเหตุ
งานที่เกี่ยวข้องกับ Debian weak keys หลังจากนั้น
- ต่อมาผู้เขียนได้มีจุดเชื่อมโยงกับ Debian weak keys มากขึ้น
- โดยดูแล pwnedkeys.com ซึ่งเป็นคลังขนาดใหญ่ของ key ที่รู้กันว่าเสียหายแล้ว
- ยังใช้ key เหล่านี้เพื่อค้นหา Certificate Authority ที่ทำงานผิดพลาด ด้วย
ความแตกต่างที่เกิดจากเวลาสำหรับไล่ตามคำว่า “แปลก”
- ผู้เขียนไม่สามารถค้นพบได้ว่า Luciano Bello ค้นพบช่องโหว่ที่กลายเป็น CVE-2008-0166 อย่างแม่นยำเมื่อใดและอย่างไร
- เนื่องจาก stable Debian release ที่มีโค้ดเปราะบางนี้ออกมาก่อนการเปิดเผยหนึ่งปี จึงอาจมีเวลาให้เห็นการชนกันของ key แล้วรู้สึกว่า “แปลก” ก่อนจะเจาะลึกลงไป
- XZ backdoor ล่าสุดก็เป็นอีกกรณีที่เชื่อมโยงกับการสังเกตว่า “แปลก” และการสืบสวนอย่างจริงจังจนถูกเปิดเผย
- ส่วนสำคัญคือความสามารถและเวลาที่จะทำ การสืบสวนอย่างจริงจัง นั้นได้จริง
- ผู้เขียนเองในตอนนั้นไม่ได้ลงลึกสืบสวนด้วยตนเอง
- ทีม GitHub ก็ยุ่งอยู่กับการพัฒนาฟีเจอร์และรับมือเหตุขัดข้องในบริการที่กำลังเติบโตอย่างรวดเร็ว
- ผู้เขียนเองก็ต้องจัดการตั๋วซัพพอร์ตที่ Engine Yard
- ความแตกต่างครั้งใหญ่เกิดขึ้นได้เมื่อมีคนที่มีทักษะ เวลา และพลังงานในจังหวะที่เหมาะสม สามารถตามร่องรอยไปจนสุดได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สำหรับข้อความที่ว่า “ยังหาข้อมูลไม่ได้ว่า Luciano Bello ค้นพบช่องโหว่ที่ภายหลังกลายเป็น CVE-2008-0166 ได้อย่างไรและเมื่อไรอย่างแม่นยำ” ในล็อก IRC ตอนนั้นมีบันทึกไว้แบบนี้
17:23 < luciano> has really an accident. I was needing many primes numbers... 0:-)17:23 < Sesse> and you got the same numbers every time?17:25 < luciano> Sesse, not every time :Pคำพูดที่ว่า “เป็นเรื่องโชคดีของวงการที่มีคนซึ่งมีทักษะ เวลา และพลังงานเหมาะสม อยู่ในจังหวะที่พอดี” ทำให้เห็นภาพของสถิติเรื่อง ยิ่งมีคนช่วยดูมาก และ “แสงแดดคือยาฆ่าเชื้อที่ดีที่สุด” ได้ชัดเจน
ต่อให้การที่ใครสักคนบังเอิญผ่านมาแล้วเจอบั๊กจะดูเป็นไปได้น้อยแค่ไหน แต่มันเป็นไปได้ จึงเกิดขึ้นจริง
ในโค้ดแบบผูกขาด/ปิด ความน่าจะเป็นนั้นเข้าใกล้ศูนย์
มีคนสังเกตเห็นสิ่งผิดปกติ และสามารถตรวจสอบสถานการณ์จริงพร้อมกับซอร์สโค้ด จนเห็นได้ว่ามีบางอย่างน่าสงสัยเกิดขึ้น
จากนั้นได้ติดต่อผู้เชี่ยวชาญด้านความปลอดภัยของดิสทริบิวชันหลัก ๆ เพื่อให้ช่วยตรวจสอบเพิ่มเติม และพวกเขาก็ยืนยันว่าเป็นประเด็นด้านความปลอดภัยก่อนจะรับมือได้ทันที
หลังการเปิดเผย ผู้เชี่ยวชาญจากหลายด้านทั้งซอฟต์แวร์และความปลอดภัยก็สามารถขุดต่อได้ว่าเกิดอะไรขึ้น อย่างไร และมีความเสี่ยงอะไรบ้าง
ยังมีการตามตรวจ commit น่าสงสัยที่นักพัฒนาคนเดียวกันทิ้งไว้ในซอฟต์แวร์อื่น และกำลังวิเคราะห์ผลกระทบต่อเนื่อง
แต่ละดิสทริบิวชันก็เริ่มไวต่อรายละเอียดมากขึ้นว่าความเสียหายเกิดขึ้นรอบ ๆ build archive ได้อย่างไร และเริ่มหาวิธีจับและป้องกันกรณีคล้ายกันในอนาคต
ถ้าเป็นซอร์สปิด มีโอกาสสูงมากที่รายงานอย่าง “ซอฟต์แวร์ช้าลงนิดหน่อย” จะไม่ค่อยได้รับความสนใจ จนกว่าจะมีการโจมตีเกิดขึ้นจริง
และถึงบริษัทจะหาสาเหตุเจอในที่สุด ก็มักจะอธิบายอย่างระมัดระวังมากโดยเปิดเผยข้อมูลเท่าที่จำเป็นเท่านั้น ซึ่งบั่นทอนความสามารถของทั้งวงการในการหลีกเลี่ยงไม่ให้เกิดซ้ำอย่างมาก
แต่มีโอกาสสูงที่จะไม่สามารถแก้ปัญหาได้ หรือไม่มีการดำเนินการใด ๆ
คนส่วนใหญ่ต่อให้พบบั๊กก็ไม่รู้ว่าควรทำอย่างไร ตัวฉันเองเมื่อหลายปีก่อนก็เป็นแบบนั้น และมารู้ทีหลังว่าสิ่งที่เคยเจอนั้นคือบั๊ก
รายละเอียดเมื่อเกือบ 30 ปีก่อนอาจเลือนรางแล้ว แต่จำได้ว่าเคยลองเล่น Microsoft NetMeeting บน Windows แล้วทำให้มันแครชได้ด้วยข้อผิดพลาดแบบ buffer overrun
ตอนนั้นยังเป็นมือใหม่ด้านคอมพิวเตอร์ และไม่เข้าใจว่า buffer overflow ในแอปพลิเคชันเครือข่ายเป็นเรื่องร้ายแรงมาก ดูเหมือนคนที่อยู่ในวงการมานานหลายคนก็เคยเป็นแบบนั้น
ในยุคนั้นการรายงานประเด็นด้านความปลอดภัยก็ยากกว่ามาก และบางกรณีก็ถึงขั้นเสี่ยงอันตราย
สุดท้ายแล้วสิ่งที่ต้องมีมีหลายอย่างพร้อมกัน ทั้งการได้พบปัญหา การเข้าใจคอมพิวเตอร์ลึกพอจะรู้ว่าปัญหานั้นร้ายแรง ช่องทางสำหรับรายงานบั๊กในที่ที่คนจะเข้ามาดู และ วัฒนธรรมด้านความปลอดภัย ที่รู้ว่าควรจัดการรายงานเมื่อไรและอย่างไร
แต่สิ่งที่สงสัยเมื่ออ่านประโยคเดียวกันนี้คือ มี บั๊กความปลอดภัยร้ายแรง อย่าง Heartbleed, CVE-2008-0166, หรือเหตุการณ์ xz เกิดขึ้นแล้วแต่ไม่เคยถูกค้นพบหรือเปิดเผยอีกมากแค่ไหน
ข้อเท็จจริงสำคัญที่เพิ่งมารู้เกี่ยวกับช่องโหว่นี้ไม่นานคือ การเปลี่ยนแปลงนี้ไม่ใช่งานที่ทำแบบรีบร้อน
ผู้ดูแลแพ็กเกจได้โพสต์ปัญหาที่ตนพบลงในเมลลิงลิสต์ของ OpenSSL ขอความเห็น และเสนอแพตช์แก้ไข โดยมีคำตอบกลับมาบางส่วนรวมถึงจาก upstream ด้วย
ผลลัพธ์กลายเป็นช่องโหว่ร้ายแรงมากก็จริง แต่ดูเหมือนจะใกล้เคียงกับ โชคร้ายสุด ๆ ที่ทุกคนพลาดประเด็นนี้ไปมากกว่า
นอกจากนี้โค้ด OpenSSL ฝั่ง upstream เองก็มีการเรียกใช้ undefined behavior อยู่ด้วย ดังนั้นถ้าคอมไพเลอร์จะแปลงโค้ดแบบเดียวกับที่ผู้ดูแล Debian ทำ ก็อาจถือว่ายังถูกต้องได้
ตอนนั้นมันฟังดูเหมือนเรื่องเชิงทฤษฎี คิดไม่ถึงว่าคอมไพเลอร์จะเล่นแรงแบบนั้นจริง
หลังจากนั้นผู้คนก็เข้าใจชัดขึ้นว่าควรหลีกเลี่ยง undefined behavior ไปเลย
แล้วอีก 8 ปีต่อมา เมื่อมีการค้นพบ Heartbleed ทุกคนก็เพิ่งตระหนักพร้อมกันว่า OpenSSL ถูกบำรุงรักษาได้แย่มากเพียงใด
หากจะพูดให้เป็นธรรม งานนี้แทบจะเป็นงานอาสาสมัครอยู่แล้ว และก็น่าโชคดีที่หลังจากนั้นสถานการณ์ดีขึ้นเพราะมีการสนับสนุนด้านเงินทุน
ถ้าเป็นโค้ดตัวสร้างเลขสุ่มที่สำคัญต่อความปลอดภัย ก็น่าจะต้องมีการทดสอบที่สร้างเลขสุ่มจำนวนมหาศาล แล้วตรวจสอบว่าทั้งหมดไม่ซ้ำกันจริง
พออ่านอะไรแบบนี้ก็อดสงสัยไม่ได้ว่า ในฟังก์ชันสร้าง seedของฮาร์ดแวร์วอลเล็ต Bitcoin ยอดนิยมสักตัวหนึ่ง เรื่องแบบนี้เคยเกิดขึ้นไปแล้วหรือมีโอกาสจะเกิดขึ้นในอนาคตมากแค่ไหน
และก็สงสัยด้วยว่าผลกระทบของมันจะเป็นอย่างไร
ตลอด 22 เดือนที่ผ่านมา Unciphered จัดการกับช่องโหว่ที่ส่งผลต่อ BitcoinJS ซึ่งถูกใช้อย่างแพร่หลายในการสร้างวอลเล็ตคริปโตบนเบราว์เซอร์ และต่อผลิตภัณฑ์·โครงการที่สร้างขึ้นด้วยซอฟต์แวร์นี้
ตลอดหลายปีที่ผ่านมา ช่องโหว่นี้ทำให้เกิดวอลเล็ตคริปโตที่เปราะบางเป็นจำนวนมาก
ในกรณีของช่องโหว่ SSH ต้องคอยตรวจเชิงรุกว่าเซิร์ฟเวอร์ที่พยายามเข้าถึงมี fingerprint ที่แย่ตัวใดตัวหนึ่งหรือไม่ แต่ฝั่งวอลเล็ตนั้นสามารถเข้าถึงเงินของคนอื่นได้โดยอัตโนมัติจากบนเครือข่าย
แต่ในกรณีนั้นก็ดูไม่น่าเป็นไปได้ว่าถูกใส่เข้ามาโดยเจตนา
ด้วยเทคโนโลยีปัจจุบันอาจต้องใช้เวลาคำนวณหลายล้านปี แต่สำหรับรัฐชาติที่มีทรัพยากรแทบไม่จำกัด อาจไม่ใช่เรื่องที่เป็นไปไม่ได้ที่จะทุ่มเงินมหาศาลเพื่อรันการคำนวณระดับนั้นให้เสร็จภายในไม่กี่สัปดาห์
ท้ายที่สุดอาจมีวันที่ใครก็ตามที่รู้ address สามารถเข้าถึงวอลเล็ตทั้งหมดได้
ถ้าคุณอาจตกเป็นเป้าหมายของใครสักคนที่มีทั้งความสามารถและเงิน Bitcoin ก็ไม่ได้ปลอดภัยนักสำหรับการเก็บมูลค่า
ประโยคที่ว่า “Ezra Zygmuntowitz ช่วยเชื่อมผมกับ GitHub และทำให้ผมมีเวลาได้เจาะลึกปัญหาร่วมกับทีม GitHub” ฟังดูชวนขำ
อาจเพราะฉันไม่ใช่เจ้าของภาษา เลยอ่านได้เหมือนกันว่ามันหมายถึงตัวทีม GitHub เองมีปัญหาใหญ่ และประโยคถัดไปน่าจะเป็นการขุดคุ้ยเรื่องนั้น
ตรงที่บอกว่า “สงสัยว่าถ้า Luciano ไม่เจอเข้า จะต้องใช้เวลาอีกนานแค่ไหนกว่าจะถูกพบ” นั้น ดูเหมือนว่าคงมีแค่ GitHub หรือผู้ให้บริการคลาวด์รายใหญ่ระดับนั้นเท่านั้นที่จะบังเอิญเจอเข้า
เพราะมีไม่กี่ที่ที่เก็บคีย์ผู้ใช้ไว้เป็นหลักหลายพันหลายหมื่นคีย์
คือควรอ่านประโยคเป็น
(เจาะลึกปัญหา) (ร่วมกับทีม GitHub)หรือเป็น(ปัญหาที่เกี่ยวกับทีม GitHub) ถูกเจาะลึกเป็นที่รู้กันว่านี่เป็นเรื่องที่จัดการให้ถูกต้องได้ค่อนข้างยาก
เท่าที่เข้าใจ ตัวสร้างเลขสุ่มของ OpenSSL ถูก seed ด้วยหน่วยความจำสแตกที่ยังไม่ถูก initialize และ PID ส่วน Debian ทำให้มันถูก seed ด้วย PID อย่างเดียว
แต่ถึงจะไม่มีแพตช์ของ Debian เดิมทีมันก็อันตรายมากอยู่แล้วไม่ใช่หรือ?
ในโค้ด OpenSSL มีอยู่สองจุดที่คัดลอกกลุ่มไบต์ และหนึ่งในนั้นอาจคัดลอกค่าขยะที่ยังไม่ถูก initialize มาได้ ซึ่งนั่นก็เป็นสิ่งที่ผิดจริง
มีคนเขียนแพตช์เพื่อแก้เรื่องนี้ แล้วต่อมาโดยไม่ต้องพึ่ง LLM และอาศัยเพียงความผิดพลาดของมนุษย์ล้วน ๆ ก็มีคนพูดว่า “แถวนี้ยังมีการคัดลอกที่คล้ายกันอีกจุดหนึ่ง ควรเอาออกด้วย”
Debian จึงใส่แพตช์ที่มีการเปลี่ยนแปลงทั้งสองอย่างเข้าไป
ผลลัพธ์คือ OpenSSL ไม่คัดลอกไบต์ใด ๆ อีกต่อไป
ข้อดีก็คือไม่มีการคัดลอกข้อมูลที่ยังไม่ถูก initialize แต่ข้อเสียคือมันก็ไม่คัดลอกentropyแบบสุ่มจริงลงในพูลด้วย แบบนี้แหละ
ตรงที่บอกว่า “หลังจากพิจารณาวิธีแก้ที่เป็นไปได้หลายแบบแล้ว เราสรุปว่าทางเลือกที่แย่น้อยที่สุดคือแพตช์ OpenSSH ให้ไปค้นหาคีย์จากฐานข้อมูล MySQL ที่ใช้นิ้วมือคีย์เป็นดัชนี” ทำไมถึงเป็น MySQL ไม่ใช่ sqlite?
ตอนนั้นกำลังพยายามเร่งการเข้าถึง ~/.ssh/authorized_keys และกรณีแบบนี้นี่แหละเหมือนเป็นสถานการณ์ที่ MySQL ถูกออกแบบมาให้โดดเด่น
การแพตช์ OpenSSH ให้ไปดู ~/.ssh/authorized_keys.db น่าจะงานน้อยกว่าการแพตช์ให้ใช้ MySQL
ก็มีโอกาสสูงว่า MySQL ถูกใช้งานอยู่แล้ว ถ้าเป็นแบบนั้นก็แทบไม่มีต้นทุนเริ่มต้นในการเก็บข้อมูลลงไปตรงนั้น
ยังไงฐานข้อมูลผู้ใช้ก็คงมีอยู่ที่ไหนสักแห่งอยู่แล้ว
นอกเหนือจากการค้นพบคีย์อ่อนจำนวนเล็กน้อยแล้ว ยังน่าสนใจที่เวลาในการล็อกอิน SSH ที่ช้าสามารถเป็นเบาะแสที่น่าลองดึงดูได้ด้วยเหตุผลหลายอย่าง
อีกเกร็ดที่น่าสนใจคือกรณีใช้ตัวหารร่วมมากที่สุดเพื่อตรวจจับคีย์ RSAที่มีตัวประกอบ
pหรือqร่วมกัน: https://factorable.net/weakkeys12.extended.pdfสงสัยว่า GitHub ยังรัน openssh ที่ถูกแพตช์อยู่หรือไม่
ซื้อ GitHub Enterprise มาสักชุด จากนั้นก็แกะการ obfuscate ของไฟล์แล้วไล่ดูได้เลย การ deobfuscate เป็นความท้าทายที่สนุกและไม่ยากมาก
น่าเสียดายที่มันไม่ใช่โอเพนซอร์ส จึงแชร์โค้ด พูดถึงรายละเอียด หรือแปะลิงก์บน GitHub ไม่ได้
ถึงอย่างนั้น ถ้า GitHub Enterprise ยังใช้แพตช์แบบนั้นอยู่ GitHub ที่ให้บริการจริงก็น่าจะมีโอกาสสูงที่จะใช้เหมือนกัน
~/.ssh/authorized_keysอีกถ้าลอง telnet ไปที่พอร์ต 22 ของ
github.comก็จะเห็นเวอร์ชันสตริงแสดงออกมาทันทีขอแก้ไขว่าตอนแรกบอกว่าเป็น golang แต่พอเช็กแล้ว ที่ใช้ golang คือ Bitbucket