HTTPS Insecurity Part 2

HTTPS Insecurity Part 1

เรื่องน่าเบื่อที่ผู้ใช้งาน Internet คงได้ยินกันบ่อย ๆ คือ การเข้า Web ให้ปลอดภัยนั้นจะต้องดูว่าเป็น HTTPS หรือไม่

หลังจาก Part 1 ได้มีการปูพื้นฐานของ PKI/Digital Certificate/HTTPS (SSL protocol) ไปแล้ว ใน Part 2 นี้จะขอพูดถึงความเสี่ยงของ HTTPS ที่สามารถเกิดขึ้นได้ครับ

Case 1: Man-in-the-Middle Attack (MITM)

การดักข้อมูลระหว่างกลางโดยอาจจะใช้เทคนิค เช่น ARP spoofing หรือ DNS spoofing เพื่อทำการ Redirect เหยื่อ (ผู้ใช้งานทั่วไป/User) ไปที่ผู้ร้าย (Attacker) แล้วผู้ร้ายจะเป็นคน forward request ต่าง ๆ ของ เหยื่อ ไป Web ที่แท้จริงอีกต่อนึง

Man in the middle attack Ref: http://www.computerhope.com/jargon/m/mitma.htm

ซึ่งการโจมตีแบบ MITM ด้วยเทคนิคทั่ว ๆ ไปอย่างเดียวมักจะไม่ค่อยประสบความสำเร็จ เพราะ User มี Security Awareness ค่อนข้างดี (มั้งครับ) และ Web Browser ของ User จะมีการ Alert ว่าเป็น Untrusted Website เนื่องจาก Attacker มักจะใช้ Self-Signed Certificate (คือ Certificate ที่ issue เอง ไม่ใช่ issue มาจาก Trusted CA) มาหลอก User ที่ไม่รู้เรื่อง และคอยแต่จะกด Continue เพื่อติดตั้ง Certificate นั้นเข้าเครื่องตัวเอง หาก User ได้ติดตั้ง Certificate เข้า Trusted List แล้ว ก็สบาย Attacker เลยครับ เพราะว่าในภายหลังหากมีการเข้า Web นี้อีกก็จะไม่ขึ้น Alert เตือนแล้ว

Case ที่ 1 นี้ก็เป็นเรื่องน่าเบื่อที่ผู้ใช้งาน Internet คงได้ยินกันบ่อย ๆ อยู่แล้วนะครับ

เพิ่มเติม อีกเทคนิคที่ค่อนข้างดังและคล้าย ๆ กับ MITM นั้นคือ Man-in-the-Browser(MITB) โดย MITB นั้นคือการดักข้อมูลที่ Web Browser ฝั่ง User เพื่อคอยแก้ไข HTTP Response เพื่อหลอก User ซึ่งหากถูกโจมตีด้วยเทคนิค MITB นี้ HTTPS ก็ไม่สามารถช่วยอะไรได้ครับ เดี๋ยวนี้พวก Malware ส่วนใหญ่จะใช้เทคนิค MITB โดยรายละเอียดเพิ่มเติมสามารถไปอ่านได้ที่บทความก่อนหน้านี้ Banking Trojan ครับ

เพิ่มเติม สำหรับเทคนิค SSLStrip นั้นจะคล้าย ๆ กับ Case ที่ 1 แต่โดยส่วนตัวผมไม่คิดว่าเกี่ยวกับ Cryptography เท่าไรนัก แต่เดี๋ยวไว้จะเขียนในบทความถัด ๆ ไปครับ

Case 2: Expired Certificate ( Certificate หมดอายุ)

ถ้าจำกันได้ในตอนที่ 1 นั้นได้อธิบายไปแล้วว่า Digital Certificate มี Validity Period อยู่ หากเลยเวลาในช่วงดังกล่าว Web Browser จะทำการแจ้งเตือนว่าเป็น Untrusted Website ซึ่งเป็นหน้าที่ของ Web Admin ที่จะต้องคอยดูแล ต่ออายุให้ Certificate นั้น ๆ โดยส่วนตัวเคยเจอกับ Website ของบริษัท/สถาบันการเงินหลายแห่ง ซึ่งก็น่าเห็นใจ Web Admin เหมือนกัน เนื่องจาก หากมี Website ที่จะต้องคอยดูแลเป็นร้อย ๆ และแต่ละ Certificate มีอายุ 1 ปี ก็แทบจะต้องต่อกันทุกวันเลยทีเดียว แต่หากจะยืดอายุ Certificate ให้นานขึ้นก็หมายถึงความเสี่ยงที่จะต้องยอมรับมากขึ้นหาก Certificate ถูก Compromised ไปครับ

Case 3: Endpoint get hacked

อีก 1 case สำหรับผู้ใช้งานทั่วไป หากโดนโจมตีไม่ว่าวิธีไหนก็ตามแล้วโดนติดตั้ง Certificate เถื่อน ๆ ทั้งหลายบน Web Browser คราวนี้คงจะวุ่นวายมากทีเดียว เพราะว่าต่อให้เข้า Web ปลอม ๆ ก็จะไม่มีอะไรแจ้งเตือนแล้ว หนึ่งในวิธีป้องกันคือการ Review Trusted List บน Web Browser บ่อย ๆ ซึ่งคงจะไม่ Effective แน่ ๆ ดังนั้นอย่างน้อยเราควรจะป้องกันเครื่องตัวเองให้รอดพ้นจากเงื้อมมือโจรร้าย ด้วยวิธีทั่ว ๆ ไปเช่น การ Update Patch, Update Application และ Update Antivirus Signature เป็นประจำ

วิธีการดู List ของ Certificate ที่มีการติดตั้งบนเครื่องเรา ดูได้ตาม Link ด้านล่างครับ

• FireFox –> https://support.quovadisglobal.com/KB/a41/how-do-i-check-my-certificates-on-firefox.aspx
• Internet Explorer –> https://support.comodo.com/index.php?\_m=knowledgebase&\_a=viewarticle&kbarticleid=1255
• อุปกรณ์ Mobile Device ก็มีการ Install Certificate เช่นเดียวกัน โดย iOS จะมาเป็นส่วนหนึ่งของ Profile ที่ install ที่เครื่อง

Case 4: Flame Malware

Malware ชื่อดังอย่าง Flame ซึ่งเป็น Malware ที่มุ่งโจมตีไปที่เครื่องในประเทศอิหร่าน โดยใช้ Certificate ซึ่งถูก issue โดย Microsoft CA หลักการในการกระจายตัวของ Flame นั้นเริ่มจากการดักจับ Request Windows Update จากเครื่องที่ยังไม่ติด Flame ใน Network วงเดียวกัน เมื่อเจอแล้วก็จะปลอมตัวเป็น Microsoft Update Server เพื่อกระจายตัวเองไปสู่เครื่องเหล่านั้น ซึ่งถือว่าเป็น MITM รูปแบบหนึ่ง แต่ว่าใช้ Certificate ที่ Valid ทำให้เหยื่อไม่สามารถรู้ตัวได้เลย

หลังจาก Flame ถูกค้นพบ ทาง Microsoft ได้รีบออก Patch เพื่อ Remove CA ที่ถูก Compromised ออกจาก Trusted List ทันที ซึ่งวิธีการป้องกันดูเหมือนจะง่ายมากสำหรับ User ทั่ว ๆ ไป แต่สำหรับองค์กรใหญ่ ๆ ที่เครื่องเป็นหมื่น เป็นแสน นั้นคงไม่สามารถทำได้อย่างรวดเร็วแน่

Microsoft Security Advisory (2718704)
Ref: http://technet.microsoft.com/en-us/security/advisory/2718704

Case 5: Compromised Certificate Authority (CA) Server

เมื่อ CA Server ซึ่งเป็น Server สำหรับ Issue Digital Certificate ถูก Compromised นั้น ทำให้มีโอกาสที่ ผู้ร้ายจะสร้าง Rogue Digital Certificate เองแล้วนำไปใช้ ทำให้ Web ของผู้ร้ายมีความน่าเชื่อถือมากขึ้น หรือเลวร้ายกว่านั้น เช่น ข่าวเมื่อประมาณ 2 ปีที่แล้วของ DigiNotar ที่ถูก Hack CA Server โดยคาดว่าผู้ทีอยู่เบื้องหลังคือ รัฐบาลของประเทศอิหร่าน ทำไปเพื่อให้สามารถ monitor/intercept traffic ของกลุ่มผู้ที่คัดค้านรัฐบาลได้ โดยมีการ issue Certificate ของ Web ดัง ๆ มากมายรวมไปถึง Google, Yahoo, WordPress, Twitter, Microsoft ซึ่ง Case ถึงกับทำให้ DigiNotar เสียหายรุนแรงจนต้องปิดบริษัทไป

CASE 6: การสร้าง Rogue CA Certificate

เทคนิคการสร้าง Rogue CA Certificate นี้เป็นเทคนิคที่ดังมากในช่วงปี 2008 – 2009 โดยจะใช้เทคนิคที่เรียกว่า Collision Attack บน Hash Function ที่มี Algorithm เป็น MD5

Hash Function คือวิธีการคำนวณรูปแบบหนึ่งที่จะ map ค่า (Value) ใด ๆ ก็ตามให้เป็นอีกค่าหนึ่งซึ่งมีความยาวจำกัด (Fixed Length) ซึ่งรายละเอียดของ Hash Function นั้นขอไม่ลงรายละเอียด เดี๋ยวจะยาวเกินไปนะครับ

สำหรับ Collision Attack คือ การโจมตีที่พยายามหาค่า (Value) ใด ๆ ก็ตาม 2 ค่าที่ process ผ่าน Hash Function แล้วได้ค่าเดียวกัน ตามตัวอย่างด้านล่าง "John Smith" และ "Sandra Dee" จะมี Hash Value ที่ตรงกันนั่นคือ "02"

MD5 เป็น Hash Function Algorithm ชนิดหนึ่ง ซึ่งปัจจุบันถือว่าไม่ปลอดภัยแล้ว จึงเปลี่ยนมาใช้ Algorithm ที่เป็น SHA แทน

การสร้าง Rogue CA Certificate โดยคร่าว ๆ นั้นเริ่มจาก

1a. Attacker เลือก CA ที่มีความน่าเชื่อถือที่ใช้ MD5 เป็น Hashing Algorithm สร้าง Digital Certificate ให้ โดยขั้นตอนนี้เป็นการ Request Certificate จาก CA ตามปกติ เช่น Request CA ให้สร้าง Web Server Certificate ซักอัน

1b. Attacker สร้าง Rogue CA Certificate ขึ้นมาโดยระบุประเภทของ Certificate นี้ให้ใช้สำหรับ Intermediate CA Server (หากเป็นประเภทอื่น Certificate นี้จะไม่สามารถนำไป Issue Certificate อื่น ๆ อีกได้) ซึ่ง Attribute ต่าง ๆ ของ Rogue CA Certificate นี้จะถูกคำนวณมาอย่างดี เพื่อให้มีค่า MD5 Hash value ที่ตรงกันกับ Digital Certificate ที่ได้จากข้อ 1a.

2. เมื่อสร้าง Rogue CA Certificate และนำไปใช้กับ Rouge CA Server แล้ว Attacker จะสามารถ Issue Digital Certificate ที่น่าเชื่อถือให้กับ Web อะไรก็ได้ตามที่ Attacker ต้องการ โดยที่การ Verify Certificate Chain จะไป Trust กันที่ระดับ CA ในข้อ 1a ซึ่ง Web Browser ทั่ว ๆ ไปจะมี Certificate ของ CA นั้น ๆ install อยู่ใน Trusted List อยู่แล้ว
3. ขั้นตอนหลอกเหยื่อให้เชื่อถือโดยการสร้าง Web ปลอม ๆ ขึ้นมาแล้วนำ Certificate ที่ Sign โดย Rogue CA Server ไปใช้งานเพื่อหลอกให้ User เข้ามาโดยส่วนใหญ่มักจะใช้พวกวิธี Phishing หรือการทำ DNS Spoofing ซึ่งคือวิธีการทำให้เครื่อง User resolve DNS แล้วได้เป็น IP address ของเครื่อง Attacker แทนที่จะเป็นเครื่องที่ถูกต้องจริง ๆ

สำหรับในตอนต่อไปเราจะมาดูกันว่าในฐานะที่เราเป็น User ผู้ใช้งานทั่วไป หรือ Admin ผู้ดูแลระบบ ควรจะต้องทำอย่างไรบ้าง

HTTPS Insecurity Part 3

ถึงตอนนี้แล้วทุกคนอาจมีคำถามว่า HTTPS ปลอดภัยหรือไม่?