It’s a bit too long for tweet, then short entry here instead 🙂
Chrome will now require ssl certificate to have Subject Alternative Name (SubjectAltName, SAN) othewrise it won’t be trusted. Which this SubjectAltName mostly missing in selfsigned certificates.
ขอเกาะกระแสของข่าว ไมโครซอฟท์รับ root CA ของรัฐบาลไทยตั้งแต่ปลายปีที่แล้ว ซึ่งนำมาซึ่งความแตกตื่นของผู้คนในวง IT ระดับนึง
ข้างล่างนี้คือความเห็นส่วนตัวล้วนๆ หลังจากที่อ่านความเห็นมาพักนึงเลยอยากลองวิเคราะห์เองบ้าง
ก่อนอื่นขอเดาว่า หลังจาก MS รับรอง root CA ของไทย ซึ่งจริงๆแล้วเป็นองค์กรในกำกับดูแลของรัฐ (NRCA ที่อยู่ภายใต้ สพธอ./ETDA) แต่ด้วยความเชือเรื่องการแทรกแทรงการทำงานของบ้านเรา อาจจะเรียกว่าเป็นของรัฐก็คงได้
ผลกระทบในคือ
กรณีเลวร้ายที่สุด – NRCA ออกใบรับรองให้ Single Gateway ของรัฐบาล ทำให้รัฐบาลสามารถทำตัวเองเป็น MITM (Man in the middle) แอบเป็นตัวกลางระหว่างเรากับผู้ให้บริการ เช่น Facebook โดยที่เราไม่รู้ตัว Web Browser หลายๆตัวก็เชื่อถือใบรับรองนี้ ทำให้การดูแค่ว่าเวลาเข้าเว็บแล้วแม่กุญแจเป็นสีเขียวก็ไม่เพียงอีกต่อไป ต้องล้วงลงไปดูด้วยว่า ไอใบสีเขียวๆเนี่ย ออกโดยใคร ถ้าออกโดย NRCA เมื่อไหร่ก็แปลว่าโดนเข้าให้แล้ว
ทางออกที่หลายๆคนเริ่มทำ และเริ่มมีบทความแนะนำให้เอาออกคือ Untrust certificate ของ หน่วยงานที่ว่า และหน่วยงานอื่นๆที่ NRCA ออกใบรับรองให้มีสิทธิออกใบรับรองอีกที (อินเซบชันกันไป) ซึ่งใครไม่ไว้ใจในหน่วยงานที่ว่า และไม่ไว้ใจในรัฐบาลก็ทำตามได้เลย ลองดูจากที่นี่ วิธีลบ root CA cert รัฐบาลไทยออกจากเครื่อง
ส่วนในมุมมองเชื่อว่า NRCA สร้างขึ้นมาเพื่ออำนวยความสะดวกให้กับโครงสร้างพื้นฐานของประเทศ มากกว่าจะมาโฟกัสเรื่อง ดักฟังประชาชน (แต่ไม่ได้แปลว่าทำไม่ได้) เพราะว่าอะไร ?
เพราะว่า Certificate ที่ออกโดย NRCA (หรือใครๆก็ตาม) นั้นมันเอาไปทำอะไรได้เยอะมาก เช่น
SSL – ใบรับรองเพื่อยืนยันว่า Server ที่เราติดต่อด้วยนั้นเป็นของจริง และเข้ารหัสข้อมูลที่ส่งหากัน
Code signing – เวลาเราพัฒนาซอฟท์แวร์ เราสามารถ Sign โปรแกรมของเราได้ว่าที่สิ่งที่ลูกค้าได้ไปนั้น เป็นของเราจริงๆ ไม่ได้มีใครแอบเอาไฟล์อะไรมาแทรกเพื่อแก้ไขมัน ทุกไฟล์จึงควรได้รับการรับรองจากเราเสมอ
Digital signing – เข้าสู่ยุค paperless, เวลาเราเซ็นเอกสาร digital เช่น pdf ก็ต้องใช้ใบรับรองเหล่านี้ ซึ่งจะตรวจสอบกับ Root CA ว่าลายเซ็นถูกต้องเป็นของจริงหรือไม่
จริงๆยังมีพวกการยืนยันตัวต้นพวก Chip บน Smartcard ต่างๆก็ต้องพึ่งพา certificate เหล่านี้
เราลองมาดูกันว่า NRCA (และบ.ที่ได้รับอนุญาติ) ออกใบรับรองอะไรไปบ้างแล้ว แล้วถ้าเรา Untrust จะกระทบอะไรหรือไม่อย่างไร ?
ลองมาไล่ดูรายละเอียดกัน
Bank of Thailand (BOT)
TDID ออกใบรับรองให้ Root CA ของ BOT ซึ่งใช้ในการเข้ารหัสการส่งข้อมูลระหว่างหน่วยงาน
ซึ่งครั้งหนึ่งผมเคยทำงานอยู่ในตำแหน่งที่ต้องเกี่ยวกับการติดตั้ง/เปลี่ยน certificate ที่ออกโดย BOT ซึ่งตอนนั้นถ้าจำไม่ผิดยังมีสถานะเป็น Self-signed การมีอยู่ตรงนี้ของ NRCA ทำให้การออกใบรับรองโดยหน่วยงานที่จำเป็นต้องใช้ มีความน่าเชื่อถือมากขึ้น มากกว่าจะ issue กันเอง trust กันเอง ซึ่งถ้าโดยแอบเปลี่ยนในขั้นตอนใดขั้นตอนหนึ่งก็เสียหายได้ ไม่ว่าจะเป็นการแอบดูข้อมูลหรือแก้ไข
NITMX CA
National ITMX เป็นบริษัทตัวกลางที่ตั้งขึ้นเพื่อดูแล ATM Pool เวลาเรามีการทำธุรกรรมผ่าน ATM “เดา” ว่าใบระบรองถูกออกให้กับ NITMX CA เพื่อใช้ใน web ที่เป็นระบบ Intranet
ใช้สำหรับระบบ Chip บน ATM ที่แต่ละธนาคารเอาไป Issue ต่อ ลองอ่านเพิ่มเติมที่เว็บเจ้าตัว http://www.thaidigitalid.com/index.jsp?page=thai_bank_chipcard.jsp
ยังมีอีกหลายอย่างที่พึ่งพากระบวนการออก Certificate ของ NRCA เช่น
ซึ่งส่วนตัวเห็นว่ากระบวนการข้างต้นเหล่านั้น จะสะดวกเมื่อการรับรอง/เพิกถอนสามารถทำได้จากหน่วยงานในประเทศ และจริงๆควรจะทำโดยหน่วยงานในประเทศเพื่อให้มั่นใจว่าไม่โดนแทรกแทรกจากตปท.
เพราะงั้นคิดว่าการมีอยู่ของ NRCA และได้รับการรับรองจาก Microsoft CA นั้นเป็นสิ่งที่ดี … ดีกว่ามี NRCA ที่ไม่มีใครเชื่อถือ
และไม่ว่าประชาชนจะ Untrust Root CA ตัวนี้หรือไม่ …. ก็คง(ยัง)ไม่มีผลกับบริการที่ NRCA และ TDID ออกใบรับรองไปแล้ว
เพราะว่าโดยปกติแล้วใบรับรอง SSL ของเว็บไซต์ก็นิยมขอขจากบริการจากต่างประเทศได้สะดวกกว่าอยู่แล้ว
สุดท้ายก็ ถ้าเห็น SSL Certificate ของเว็บทั่วๆไปออกโดย NRCA หรือ TDID เมื่อไหร่ ก็ .. ตัวใครตัวมันล่ะ … ซึ่งสองหน่วยงานที่ว่าถ้าโดน report เมื่อไหร่ คิดว่า MS ก็คงไม่ปล่อยไว้
ปล. เหตุการณ์แบนี้อาจจะไม่ได้เกิดขึ้นแค่ในระดับประเทศเท่านั้น ในบริษัทที่เครื่องคอมพิวเตอร์อยู่ภายใต้ Domain เดียวกัน บริษัทก็สามารถส่ง Certificate “ใดๆ” มาให้เครื่องคอมพิวเตอร์ในโดเมน trust ได้ แล้วก็ทำ Main in the middle ได้เช่นเดียวกัน
ปล2. ผมไม่ได้มีส่วนได้ส่วนเสียใดๆกับใครในเรื่องนี้ (ฮา) ผิดพลาดอะไร เข้าใจอันไหนไม่ตรงกันคอมเม้นชี้แนะด้วยคับ
References:
รูปภาพและการให้บริการของ TDID มาจาก www.thaidigitalid.com
อีกหนึ่งความเห็นที่น่าสนใจของ NRCA https://www.facebook.com/X20AThinkpad/posts/1759466287412850
หลายๆคนที่กินสตาร์บัคส์บ่อยๆ น่าจะมีสตาร์บัคส์การ์ดเป็นของตัวเอง เพราะจะได้สะสมดาวเอาไว้รับสิทธิพิเศษนู่นนี่นั่น … อย่างที่เหยื่อการตลาด(อย่างเรา)ควรจะเป็น
แต่การที่เป็นเหยื่อการตลาด ไม่ได้หมายความว่าเราจะต้องเป็นเหยื่อของการขโมยรหัสผ่านด้วยในคนเดียวกัน ..
เรื่องของเรื่องคือ เมื่อสักสองสามสี่ห้าปีก่อน สตาร์บัคส์ประเทศไทยได้รื้อระบบสตาร์บัคส์การ์ดที่ใช้ร่วมกับประเทศอื่นๆ แล้วทำของตัวเองขึ้น …
สิ่งที่ตามมาก็คือเปิดให้สมาชิกลงทะเบียนสตาร์บัคส์การ์ดของตัวเองได้ มีแอพเช็คยอดเงิน ตรวจสอบสิทธิพิเศษ บัตรหายก็ขอใหม่ได้เพราะเราผูกกับบัญชีผู้ใช้เราแล้ว (ควรจะ)ออกบัตรใหม่ได้เลย เงินอยู่ครบ
ก็เหมือนจะดี .. แต่แน่นอนว่าถ้าดีก็คงไม่บ่น 555+
เหตุผลคือ … ณ ไตรมาสสุดท้ายของปี 2016 แต่เว็บ www.starbuckscard.in.th ยังไม่บังคับให้เข้าเว็บแบบเข้ารหัส … เท่านั้นยังไม่พอ หน้าล็อกอินของ starbuckscard เองก็ไม่ได้บังคับให้เข้ารหัสเช่นเดียวกัน
หมายความว่า …. ตอนล็อกอิน … ทุกๆจุดที่ข้อมูลคุณผ่าน จากบ้านถึง server ของ starbucks สามารถเห็น email/password ของคุณได้หมด ตั้งแต่คนดูแลเน็ตเวิร์คที่ทำงาน ยันพนักงานที่ ISP ..
ถ้าหากคุณรอดพ้นหน้า Login เข้ามาได้ (ยังไงวะ) … ท่าไม้ตายที่ทำให้มันแย่ได้อีกก็คือ .. การเปลี่ยนพาสเวิร์ด
ปกติการเปลี่ยนพาสเวิร์ด เป็นการธรรมดามากที่จะต้องตรวจสอบรหัสผ่านเดิมก่อน เพื่อให้มั่นใจว่าเป็นเจ้าของเองจริงๆ ถึงแม้ว่าจะล้อกอินอยู่แล้วก็ตาม ซึ่งเว็บนี้ก็ทำนะ .. ทำฝั่ง Client คือ พี่แกส่งรหัสผ่านมาในหน้าเว็บเลย เวลาเรากรอกรหัสเดิม มันก็รู้ได้เลยโดยไม่ต้องถาม server ให้เหนื่อย … ซึ่งเหมือนเหมือนจะดี แต่มันไม่ !!
โดยปกติเว็บไซต์ควรจะเก็บพาสเวิร์ดของเราแบบเข้ารหัสทางเดียว หมายความว่าคนดูแลเว็บเอ็งก็ไม่(ควรที่จะ)สามารถรู้ได้ว่ารหัสผ่านของเราเป็นอะไร เพื่อที่ว่าเวลาข้อมูลหลุดไปอย่างน้อยผู้ไม่ประสงค์ดีก็จะไม่ได้เอาไปใช้ได้เลย
แต่เว็บนี้นอกจากจะไม่ได้เข้ารหัสทางเดียวแล้ว ยังส่งรหัสผ่านกลับมาที่ Client เพื่อตรวจสอบด้วย ประกอบกับความแย่ของการไม่บังคับเว็บให้เข้ารหัส SSL ผลก็คือ รหัสผ่านของคุณก็วิ่งพล่านไปทั่วระบบเครือข่าย รอใครซักคนมาหยิบเอาไป … ยิ่งถ้าคุณใช้รหัสผ่านและอีเมลเดียวกับบริการอื่นๆแล้วละก้อ …. ความซวยอาจจะมาเยือนได้
คำแนะนำ
ถ้าการเลิกใช้ไม่ได้เป็นหนึ่งในทางเลือก ก็แนะนำให้
ถ้าใครว่างลองแงะแอพบน Android กับ iOS ทีว่าเข้ารหัสด้วยมั๊ย ….
จริงๆแอบคาดหวังให้บริการที่เกี่ยวของกับการเงินมีความปลอดภัยมากกว่านี้ … บริการนี้มันเกือบจะเข้าข่ายบัตรเงินสดด้วยซ้ำไป มีหน่วยงานไหนจะต้องตรวจสอบบ้างมั๊ยน้า …
ปล. รหัสผ่านด้านบนนี่เอาไปลองได้ 555+
ปล2. อีกเรื่องที่ไม่ชอบคือ ทำไมต้องพิมพ์ชื่อนามสกุลของเราลงในใบเสร็จทุกครั้งที่ซื้อด้วย … privacy ของเราอยู่ที่ไหน !!
ปล3. ถ้าสังเกต code ที่ highlight ในรูปที่สอง จะพบว่าคนพัฒนาเอารหัสผ่านมาใส่ในช่อง input ที่มี type เป็น color !!!!! … มันก็ error เด๊ ….
ปกติเวลา account online ใดๆของเราจะโดนแฮกเนี่ย โดยส่วนใหญ่จะเป็นไปได้สองกรณี คือ
– เราถูกแฮกอยู่คนเดียว (ซวยโคตร) หรือ
– บริการนั้นๆโดนแฮก ข้อมูลผู้ใช้บริการ รหัสผ่าน หรือาจจะรวมถึงข้อมูลบัตรเดรดิตหลุดออกสู่สาธารณะ (ซวยกันทั้งหมด)
ที่ผ่านๆมาเคยเขียนวิธีป้องกันกรณีแรก ที่หลายๆครั้งจะโดนทำ Social Engineering จำพวก คำถามลืมรหัสผ่านง่ายเกินไป จดรหัสผ่านพร่ำเพรื่อ หรือแชร์รหัสกับคนอื่น ซึ่งการใช้รหัสยากๆ อาจจะช่วยได้บ้าง เคสนี้ยังรวมถึงพวกติดไวรัส ไม่ว่าจะเป็นบนคอมหรือบนมือถือ หรือที่ Router หรือแม้กระทั่งโดนพวกเว็บ phishing ซึ่งการใช้โปรแกรมป้องกันไวรัส ไม่เข้าเว็บที่สุ่มเสี่ยง หรือถ้าเข้าก็ใช้พวกโหมดพิเศษใน Browser ที่ไม่ทิ้งร่องรอยเราเอาไว้ รวมถึงการใช้ล็อกอินสองชั้น (2 steps verification / multi-factor authentication) ก็จะยิ่งช่วยป้องกันได้มากขึ้น
คราวนี้เราลองมาดูกรณีที่สองกันดูบ้าง คือ Service ที่เราใช้บริการนั้นโดนแฮก ซึ่งเกิดขึ้นไม่ง่าย แต่ก็ไม่ได้ยากจนเกินไปนัก ยิ่งเดียวนี้ Startup ผุดเป็นดอกเห็ด เรายิ่งต้องรู้อะไรพวกนี้ไว้บ้าง
โดยมีข่าวสดๆร้อนๆที่น่าสนใจสองอันคือ LinkedIn เคยถูกแฮกเมื่อปี 2012 .. แล้วข้อมูลก็เพิ่งจะถูกปล่อย(ขาย)สู่สาธารณะเมื่อเร็วๆนี้ หลุดแล้วเป็นร้อยล้านรายการ
อีกข่าวที่เป็นของไทย คือ เว็บ e-commerce รายนึงในไทยพัฒนาการเชื่อมต่อกับ Payment Gateway ที่ไม่รัดกุมพอ ทำให้ข้อมูลบัตรเครดิตลูกค้ารั่วไหล (แถมยังไม่ยอมรับอีก) (แถมตอนนี้เปลี่ยนชื่อไปอีก)
เรื่องการป้องกัน เราคงทำอะไรเองไม่ได้มากนัก ทำได้ก็คงเลือกใช้บริการเจ้าที่ดูน่าปลอดภัยหน่อย อีกอย่างนึงที่เริ่มได้ง่ายๆก็คือ พยายามอย่าใช้รหัสในแต่ละเว็บไซต์เหมือนๆกัน เพื่อจำกัดความเสียหายในกรณีที่ข้อมูลหลุดจากที่นึง จะได้ไม่ทำให้บริการอื่นๆเสี่ยงไปด้วย
อีกเรื่องนึงก็คงเป็น 2 steps verification ที่ช่วยให้แม้ว่าข้อมูล username/password ของเราหลุดออกไป คนอื่นก็เอาไป login ใช้งานไม่ได้ .. เห็นมั๊ยว่าล็อกอินสองชั้นเนี่ย มันช่วยได้ทั้งสองกรณีเลย 😀
แล้วเราทำอะไรได้อีก ?
มีบริการอันนึงที่คุณ Troyhunt เป็นพนง. Microsoft ทำส่วนตัวขึ้นมา .. เป็นเว็บไซต์ชื่อ haveibeenpwned.com
สิ่งทีเค้าทำก็ง่ายๆเลยคือ รวมรวบข้อมูลที่ถูกแฮกแล้วปล่อยออกมาสู่สาธาณะ ตรวจสอบว่าเป็นของจริง แล้วก็เอามาใส่ในเว็บดังกล่าว (ถ้าสนใจ เค้าเขียนวิธีที่เค้าตรวจสอบข้อมูลที่ถูกปล่อยออกมาไว้ ที่นี่ )
เราสามารถใช้ประโยชน์จากมันได้ คือ ตรวจสอบ username / email ของเราว่ามีอยู่ในฐานข้อมูลของเว็บหรือไม่ .. ถ้ามีนั่นแปลว่าคุณโชคร้ายแล้วคับ … ข้อมูลของคุณมีความเสี่ยงที่จะโดนใช้งานโดยผู้ไม่ประสงค์ดี ไม่ทางใดก็ทางหนึ่ง … ควรเปลี่ยนรหัสผ่านโดยด่วน แล้วยิ่งถ้าใช้รหัสผ่านเดียวกันหลายๆเว็บไซต์ นี่เปลี่ยนยกแผงเลยครับพี่น้อง !!!
โดยทางเว็บจะบอกบริการที่ข้อมูลนี้หลุดออกมา รวมถึงที่อื่นที่พบข้อมูล(เว็บจำพวก pastebin) และข้อมูลที่หลุด เช่น อีเมล username รหัสผ่านแบบเข้ารหัส หรือรหัสผ่านแบบ plain text (สยองโคตร) คำใบ้รหัสผ่านก็ยังมี มีคำแถลงการของเจ้าของบริการที่ทำหลุดหรือไม่
เว็บยังมีสิ่งที่เรีกยว่า Notify me .. คือให้เรากรอก email ไว้กับเว็บไซต์ แล้วทางเว็บจะเตือนเราถ้ามีข้อมูลอีเมลของเราหลุดมาในอนาคต .. วันนี้ยังไม่มีไม่ได้แปลว่าวันข้างหน้าจะไม่มี … ตั้ง notify ไว้ก็คงไม่เสียหาย (ถ้าอีเมลหลุดจากเว็บนี้อีก ก็คงซวยซ้ำซวยซ้อนจริงๆ แต่เว็บก็ไม่ได้เก็บอะไรมากกว่าอีเมล)
Good luck have fun !!
เพิ่งเจอช่องโหว่กับตัวเองมาสดๆร้อนๆเลย ขอเริ่มเลยละกัน
เมื่อวานได้จองตั๋วเครื่องบินกับสายการบิน Emirates ซึ่งก็ไม่มีอะไรผิดปกติ ..
จนกระทั่งถึงขั้นตอนชำระเงิน ก็จ่ายเงินผ่านบัตรดิตของธนาคารไทยพาณิชย์ (SCB) แบบ Visa ซึ่งก็กรอกข้อมูลเหมือนเว็บอื่นทั่วๆไป เลขที่บัตร ชื่อ นามสกุล วันหมดอายุ เลข ccv
หลังจากนั้นก็เข้าสู่หน้าจอ Request OTP ซึ่งมีโลโก Visa กับ SCB หลังจากกดขอรหัสผ่านไป .. ผ่านไป 20 วิ ยังไม่ได้รับ SMS
กด Request ซ้ำอีกที .. ก็ยังไม่ได้รับ SMS…. กดซ้ำอีกที จนปุ่มแม่ง disbale ไปล่ะ .. ก็ยังไม่ได้ SMS
ถึงจุดนี้ก็โทรหา Call center SCB ล่ะ ว่าทำไมไม่ได้ SMS … จนท.ก็ตรวจสอบนู่นนี่
บอกว่าระบบส่ง OTP ออกมาแล้ว 3 ครั้ง เค้าทำอะไรให้ไม่ได้ อาจจะเป็นที่เครือข่ายโทรศัพท์ (ถึงจุดนี้บางคนอาจจะโดนให้ช่วยลองส่ง sms ล่ะ) .. เบอร์ที่ใช้อยู่เป็น AIS .. (คือแม่งมีหลาย Party มาก ไม่รู้จะเริ่มด่าใครดี) แต่หลังจากลองๆ SMS ก็ยังทำงานได้ปกติ รับเข้าส่งออกได้
นั่นมันเพียงแค่จุดเริ่มต้นเท่านั้น คือพอไม่ได้ SMS ก็ทำอะไรต่อไม่ได้ เลยกด Cancel ออกมา .. หน้าจอของ Emirates ก็ขึ้นว่า error อะไรซักอย่าง จำไม่ได้ ซึ่งก็คาดเดาได้ เพราะทำรายการไม่สำเร็จ
หลังจากนั้นก็เริ่มจองตั๋วใหม่ … พอจองๆไปได้ครึ่งทางก็มี SMS เข้ามา .. ตอนแรกก็เดาว่าเป็น OTP ที่มาช้า
แต่ไม่ใช่มันเป็น SMS ที่บอกว่า Transaction สำเร็จ (วงเงินหายไปเท่าราคาตั๋ว)
เจอ SMS นี่เข้าไปก็ชอค !!! โทรหา Call center อีกที … จนท.ก็โอเคนะขอทำ 3 สายกับทาง Emirates .. ผลปรากฏว่า Emirates ยืนยันว่ารายการสำเร็จ ชำระเงินเรียบร้อย …. แต่ว่า เฮ่ย … กรูไม่ได้กรอก OTP นะ .. แถมกด Cancel ด้วยซ้ำ ทำไมมันสำเร็จวะ ???
หลังตรวจสอบว่าได้ตั๋วแล้วจริงๆก็กลับมาถามจนท. SCB อีกทีว่าทำไมไม่กรอก OTP แล้วรายการยังสำเร็จ ?
คำตอบที่ได้จากจนท.คือ “มันแล้วแต่เว็บไซต์ว่าจะดู OTP หรือไม่ บางเว็บไซต์อาจจะดูแค่ว่า CCV ถูกต้องก็ให้ทำรายการแล้ว”
คือแบบ … จากที่เคยคิดว่า OTP (ที่แลกมาด้วยความยุ่งยาก) จะปลอดภัยขึ้น ซึ่งในความเป็นจริงมันไม่ได้เป็นแบบนั้นเลย … แสรสส
สุดท้ายนี้ก็ดูแลเลข ccv หลังบัตรให้ดีๆกันครับพี่น้อง 😉
