By: lew 
on 23 February 2017 - 23:21
Tags:
Topics:
ค่าแฮช SHA-1 มีรายงานว่ามีช่องโหว่จนอ่อนแอกว่าที่ออกแบบไว้อย่างมาก มานานหลายปี โดยกูเกิลประกาศให้ใบรับรองที่รับรองโดย SHA-1 ไม่ปลอดภัยมาตั้งแต่ปี 2014 แต่จนกระทั่งวันนี้ก็ยังไม่มีใครปลอมไฟล์ที่มีค่าแฮช SHA-1 ตรงกันได้จริงๆ ล่าสุดทีมวิจัยร่วมระหว่างมหาวิทยาลัยอัมสเตอร์ดัม และ Google Research ก็สามารถสร้างไฟล์ PDF สองไฟล์ที่ค่าแฮชตรงกันได้สำเร็จ โดยใช้ชื่อกระบวนการปลอมไฟล์นี้ว่า SHAttered
ไฟล์ shattered-1.pdf และ shattered-2.pdf มีค่าแฮช SHA-1 เป็น 38762cf7f55934b34d179ae6a4c80cadccbb7f0a ทั้งคู่ แต่ค่าแฮช SHA-256 กลับต่างกัน
SHAttered สร้างค่าแฮชถึงเก้าล้านล้านล้านรายการเพื่อหาไฟล์ที่ค่าแฮชตรงกัน โดยใช้ชิปกราฟิก 110 ชุดรันเป็นเวลา 1 ปี
บริการ Google Cloud ให้เช่าชิปกราฟิกใช้งานชั่วโมงละ 0.7 ดอลลาร์ ชิปกราฟิก 110 ชุดเวลาหนึ่งปี จะเป็นต้นทุน 674,520 ดอลลาร์ แต่หากใช้เครื่อง g2.8xlarge ของ AWS ในราคา Spot Instance ที่ราคาประมาณ 0.5 ดอลลาร์ต่อชั่วโมงได้การ์ด 8 ใบ ต้นทุนรวมจะเหลือเพียง 110,000 ดอลลาร์ Bruce Schneier เคยทำนายไว้ว่าจะใช้ต้นทุน 700,000 ดอลลาร์ในปี 2015 และ 173,000 ดอลลาร์ในปี 2018 งานวิจัยในปี 2015 เคยระบุว่าจะใช้ต้นทุนเพียง 120,000 ดอลลาร์
ความเสี่ยงร้ายแรงที่สุดคงเป็นระบบ Git ทั้งหมดที่ใช้ค่าแฮชแบบ SHA-1 เพื่อระบุการ commit ในอนาคตแฮกเกอร์ที่ต้องการปลอมแปลงโค้ดใน Git สามารถสร้าง commit ที่ค่าแฮชตรงกันแต่เนื้อไฟล์ต่างกันได้ ตอนนี้แอปพลิเคชั่นใหม่ๆ ก็ควรเลิกใช้งาน SHA-1 ทั้งหมด
ที่มา - SHAttered.io
Get latest news from Blognone
Follow @twitterapi
Blognone Jobs Premium
Cloudnone
- Kubernetes คืออะไร [Part 1] เกิดขึ้นมาอย่างไร? ทำไมต้องใช้มัน? | Cloudnone EP.14
- CI/CD ยังไงดี ตั้งเซิร์ฟเวอร์เอง vs เช่าคลาวด์ | Cloudnone EP.13
- รู้จักโน้ตบุ๊กบนคลาวด์ เช่าใช้งาน Jupyter Notebook ที่ไหนดี | Cloudnone Ep.12
- สรุปข่าวใหญ่ปี 23 และคาดการณ์เทรนด์ปี 24 ในวงการ Cloud | Cloudnone EP.11
- สรุปของใหม่และสาระสำคัญจาก AWS re:Invent 2023 | Cloudnone Special EP
Comments
ต้นทุนสูงมากและใช้เวลานานถึง 1 ปี กว่าจะทำได้สำเร็จ
กว่าจะทำสำเร็จถึงเวลานั้นคนส่วนใหญ่ก็เลิกใช้ไฟล์นั้นแล้วมั้งครับ คนโหลดคงน้อยมากแล้ว
git repo จะอยู่คู่กับเราไปอีกนานครับ การอ้างอิงด้วยค่าแฮชจะต้องใช้ไปอีกหลายปี ซอฟต์แวร์ที่อ้างอิงค่า commit ทั้งหมดกว่าจะอัพเดตได้
110k USD อยู่ในวิสัยของ องค์กรขนาดใหญ่, การโจมตีระดับรัฐ พวกนี้อยากยัดยาเข้าองค์กรฝ่ายตรงข้าม ปลอมโค้ด ปลอม executable มูลค่าเกินทั้งนั้นครับ จรวดลูกถึงแพงกว่านี้เยอะ (มูลค่าความเสียหายของฝ่ายที่ถูกกระทำยิ่งแพงหนัก)
lewcpe.com, @wasonliw
ไม่ใช่ครับ สมมติว่าคุณเซ็นต์เอกสาร A ด้วย SHA-1 ไว้ จะทำให้ผู้ประสงค์ร้ายสามารถสร้างเอกสาร B ซึ่งเนื้อหาเป็นอะไรก็ได้ แล้วใช้ลายเซ็นต์ของคุณจากเอกสาร A เพื่อปลอมว่าเอกสาร B คุณก็ได้เซ็นต์แล้วเช่นกันได้ครับ ซึ่งถึงเอกสาร A จะอายุ 1 ปีแล้วก็ไม่มีปัญหาครับ
ถูกมากๆ และครับถ้าเอกสารนั้นเป็นสัญญาณมูลค่าหลายล้าน+++แต่ดันใช้ SHA-1 ยืนยันข้อมูล ซึ่งจะกลายเป็นว่า SHA-1 ตัวนั้นเป็นตัวจริงหรือไม่...
1 ปีเมื่อปีที่แล้วครับ เริ่มรันอีกทีตอนนี้อาจจะเหลือ 6 เดือนเพิ่ม Spec เครื่องอีกหน่อย ก็ 3 เดือน
อีกอย่างในเชิง programming ผมว่าตัวไฟล์ที่เป็นเป้าหมายคงไม่ใช่ไฟล์ที่เป็น release สำหรับ user ครับ น่าจะเป็นพวก core-code programing หรือ binary files ที่เอาไป build ต่อ เพราะไฟล์ประเภทนี้เค้าไม่ได้เปลี่ยนกันบ่อยครับ
ส่วนต้นทุนผมว่าไม่สูงนะครับ หรือถึงจะสูงก็ลดเรื่อยๆ คุ้มค่ากับการฝังและขายช่องโหว่
"โดยใช้ชิปกราฟิก 110 ชุดรันเป็นเวลา 1 ปี"
ถ้าใช้เพิ่มเป็น 1000 ชุด เวลารันจะลดลงหรือไม่?
น่าจะลดลงล่ะครับ ประเด็นคือเงินทุนต่ำสุดน่าจะอยู่ที่ประมาณสี่ล้านบาท (ค่าเช่าคลาวด์)
lewcpe.com, @wasonliw
ในทางกลับกัน แปลว่า หากเป็นองค์กรที่ไม่มีข้อจำกัดเรื่องต้นทุน ถ้าใช้เพิ่มเป็นหมื่นๆ ชุด หรือใช้เครื่องที่สเปคสูงกว่านี้ อาจใช้เวลาไม่ถึงวันในการปลอม
ถึงได้พยายามแข่งสร้างซูเปอร์คอมพิวเตอร์กันจัง จริงๆแล้วแต่ละประเทศก็แอบเอามาใช้เพื่อเรื่องพวกนี้รึเปล่า
อื้อหือ อันตรายมากเลยนะนั่น เดี๋ยวแป๊บ ๆ ก็ลดลงอีกทั้งค่าใช้จ่ายและเวลา ปีนึงจะเปลี่ยนกันทันเหรอ
เทคโนโลยีไม่ผิด คนใช้มันในทางที่ผิดนั่นแหละที่ผิด!?!
เรื่องเงินไม่ใช่เรื่องใหญ่นะผมว่า เรื่องเวลานี่สิ ที่พวกเข้ารหัส ที่ออกแบบมาเพื่อถ่วงเวลาหรือทำให้ปรกติแล้วถอดไม่ง่ายถ้าไม่มี key ผมว่าถ้า run งานพวกนี้บน super computer ยิ่งเสร็จเร็วไปอีก สรุปแล้วมันไม่ปลอดภัยเลย
อีกหน่อยอาจจะมี cracking coin ก็ได้ใครจะไปรู้
พอมีคน submit job ปุ๊บ cracking coin miner จะทำการไปหยุด gpu base xxxcoin miner ก่อน
จากนั้นก็เริ่มป้อนงานใหม่ใช้ gpu ถ้างานสำเร็จก็จะได้ cracking coin มาใช้
จากนั้นเอาไปแลกเป็น bitcoin ต่อ หรือแลกเป็นเงิน ก็ว่ากันไป
ปัจจุบันอาจจะแอบโยนพวกนี้มาให้นักขุดโดยไม่รู้ตัวแล้วก็ได้!
ในฐานะที่เคยเช่า Spot Instance ใช้งานในลักษณะดังที่กล่าวมา ตอนแรกผมสงสัยว่าต้นทุน Spot Instance มันนำมาใช้อ้างอิงตรงๆ ได้ด้วยหรือในงานลักษณะดังกล่าว ยิ่งในงานที่รันนานๆ เพราะมันต้องถูก Terminate Instance อยู่เรื่อยๆ แต่พอมานั่งคิดวิเคราะห์ดูอย่างละเอียด มันน่าจะมีวิธีการจัดการกับตัวแปรต่างๆ ที่นึกขึ้นมาได้ในทีแรก ที่โดยในท้ายที่สุดแล้วทำให้ต้นทุนไม่ได้เพิ่มขึ้นแตกต่างอย่างมีนัยสำคัญเท่าไร
ถ้าแก้แบบง่ายๆไปก่อนด้วย double hash
อาจจะดี
เช่น sha1 + md5
ทำให้ ต่อให้แก้จน sha1 ตรงได้
md5 ก็จะไม่ตรง?
ถ้าต้องแก้ถึงขนาดนั้น แก้เป็น SHA-2, SHA-3 ไปเลยไม่ง่ายกว่าหรือครับ? ใช้ hash ครั้งเดียวเหมือนเดิมด้วย
ไม่เชี่ยวชาญเรื่องนี้ แต่แค่รู้สึกว่า
ทาง security ใช้ 2 hash ซ้อน (เก็บปลายทางค่าเดียว) ไม่เวิร์คก็จริง (เพราะจะได้ strength เท่า hash ที่อ่อนแอสุด)
แต่ถ้าเก็บ 2 hash แยกมันน่าจะเวิร์คกว่านะครับ
สมมติ sha-2/3 แตก (ซึ่งไม่น่าแตกง่ายขนาดนั้น)
การจะ craft content ให้อยู่ในสภาพเดิม โดยเหมือนกันทั้งสอง hash เลยน่าจะยากกว่าหรือเปล่า
กว่าจะได้ sha-1 ตรงก็นานแล้ว
ปรากฎว่า sha-1 ที่ตรง ดันไปทำให้ hash อื่นเพี้ยน
แต่ในแง่ของคำนวณ ก็เปลืองขึ้นป่าวหว่า
ปล. ผมไม่รู้ผมเดา
คือเห็นเค้าเสนอให้แก้แบบง่ายๆ น่ะครับ การแก้ให้รองรับการเก็บและตรวจสอบ hash ถึงสองแบบสองค่านี่ไม่ง่ายเท่าเปลี่ยนฟังก์ชัน hash อย่างเดียวมั้งครับ?
ยังไม่นับว่าหา hash สองรอบจะกินประสิทธิภาพไปขนาดไหนอีก
จริงๆก็แบบนั้นล่ะครับ
เรื่อง security พวกนี่ดันเป็น pure math เลยไม่รู้ทางไหนเวิร์คกว่า
(rehash ของเดิมใหม่หมด กับ rehash ด้วยฟังก์ชันง่ายๆ แล้วเก็บเพิ่ม)
ในแง่ของการ sign เอกสารก็อาจจะ sign 2 รอบ อาจจะเซฟกว่าระยะยาว
(ต้อง forge ให้ comply ทั้งสอง hash ดูวุ่นวายดี)
สำหรับ github ถ้าต้อง rehash ใหม่หมด สำหรับของเดิม
(หรือ ใช้ hash ใหม่สำหรับของใหม่) อาจจะต้องดูหลายมุม
จริงๆหลังจากนี้แค่ทยอยเปลี่ยนมาใช้ stronger hash ก็พอแล้วละครับ
แต่ของเดิมรอเค้าเลือกกัน
SHA1 เบรคมานานล่ะ แต่อย่างถ้าผมมองว่าสำหรับเก็บรหัสผ่านมันก็เซฟอยู่ดี
เพราะจำกัดด้วยความยาวรหัสผ่าน (ไม่มีพื้นที่ให้ forge) และประเภทตัวอักษร
(ไม่มี sample space สำหรับตัวอักษรที่พิมพ์ไม่ได้)
แต่ถ้าสร้างใหม่ ก็ไปใช้แฮชแบบใหม่แทน
ผมเข้าใจว่า การสร้าง hash สร้างที่ฟาก server
การแก้แนวทางปกติคือ ให้ server เปลี่ยนเป็น sha-2 แล้วเก็บแค่ค่าเดียว
แต่ผมกลับคิดว่าแก้โดยเพิ่ม field md5 ไปอีกตัว
ซึ่งต่อให้ craft จน sha1 แตกได้, md5 จะเป็นตัวฟ้องว่าไม่เหมือนอยู่ดี
ผมคิด(เดา)ว่า การจะ craft ให้ตรงทั้ง sha1 กับ md5 พร้อมๆกัน
น่าจะยากกว่าการ craft ให้ตรงกับ sha2,sha3 นะ
ซึ่งมันน่าจะดี เพราะวิธีนี้ ทำรอบเดียวแล้วอยู่ไปเลยยาวๆ
แต่ก็ไม่แน่ใจว่า วิธี sha1 + md5 จะกินทรัพยากรมากกว่า sha2 หรือเปล่า?
เพราะมันเป็นการใช้
วิธีง่ายๆ 2 ครั้ง vs วิธียากๆ ครั้งเดียว
sha1 = 160 bit
md5 = 128 bit
รวมกันได้ 288 bit
sha2 มีให้เลือกใช้ตั้งแต่ 224/256/384/512 bit ถ้าอยากให้ sha2 แข็งกว่า md5+sha1 ก็เลือกใช้ sha2 แบบ 384-bit ครับจบ
ต่อให้มองแบบอุดมคติเลยว่า md5 และ sha1 เป็น algorithm ที่สมบูรณ์แบบมาก ไม่มีการชนเลย มันก็ยังแพ้ sha-384 อยู่ดีครับ
+1
คำตอบนี้ ชัดเจนดี
ต่อให้มันปลอดภัยกว่าจริงๆ (ซึ่งคุณ Lancaster ก็ชี้แจงไปแล้วว่ามันไม่น่าจะปลอดภัยกว่า sha-2 ตัวเดียว) แต่ถ้าแบบนั้นทำไมไม่ทำ sha2 + sha3 แทน sha1 + md5 ล่ะครับ? md5 นี่ชื่อเสียร้ายแรงยังกับอะไรดี
หลักการเลือกเอากระบวนการเข้ารหัสที่รับรู้โดยทั่วกันว่ามีจุดโหว่แล้วมาใช้ 2 ครั้งนี่มันไม่มีใครเขาใช้กันครับ เพราะคุณต้องมาตามว่าจุดโหว่ของมันอ่อนแอไปถึงระดับไหนแล้ว
คุณสร้าง SHA1 ที่เหมือนเดิมแต่สุดท้ายซอฟต์แวร์ของคุณเองก็ต้องปรับเพื่อให้เช็คค่าแฮชสองครั้ง (ซึ่งซอฟต์แวร์ที่ใช้ค่าแฮชเยอะๆ เช่น Git มันไม่ได้เปลี่ยนง่ายขนาดนั้น)
งานเยอะแน่นอน ความปลอดภัยรับประกันไม่ได้ (คุณเองก็บอกว่าไม่แน่ใจ) มันเลยไม่มีใครทำ สู้ไปใช้แฮชที่รู้ว่าปลอดภัยทีเดียวจบเรื่อง งานเยอะแน่แต่แก้ปัญหา
lewcpe.com, @wasonliw
ของผมมองว่า
- จริงๆ ในแง่จำนวน secure bit sha-2 หรือตัวอื่นมันดีกว่าอยู่แล้วล่ะครับ
- จริงๆ ถ้าไม่ได้เจอเรื่อง SHAttered เนี่ย SHA-1 ก็สตรองประมาณนึงนะ พอเป็น SHA-2 มันโดดไปอีกขั้นเลย
- แต่ที่คิดว่าใช้แค่ CRC/MD5/Checksum ง่ายๆเอานี่คือแบบแค่สโคปเฉพาะงาน rehash ไฟล์เก่าทั้งหมด
(ที่ไม่ถูกแก้ไขเลยมานานมากแล้ว + เฉพาะในด้านหลังบ้านเป็นหลัก) เพราะต้นทุนการ hash checksum ธรรมดาถูกกว่ามาก (แต่จริงๆก็ไม่ได้มากขนาดนั้นเพราะต้นทุนแพงสุดคือการอ่านข้อมูลจาก disk) ...
แต่จริงๆก็มองได้ว่ามีเวลานานพอสมควรในการ rehash ใหม่ ทำใหม่หมดเลย บนของใหม่เลยก็น่าจะได้แหล่ะมั๊งครับ