17 ตุลาคม 2560

WPA2 Key Reinstallation Attack (KRACK)

ช่องโหว่ WPA2 ของ Wireless LAN ทำให้ชีวิตดูเหมือนอยู่ยาก แต่อย่างไรก็ตามอาศัยความรู้อันน้อยนิด ให้ความกระจ่างได้ดังนี้
1. เนื่องจากต้องทำ Rouge Access Point in the Middle ดังนั้นถ้าบ้านคุณไม่ใหญ่จนคนมาทำ Access Point ปลอมในบ้านคุณได้ ก็ไม่ต้องวิตกกังวลอะไรนัก หรือแม้แต่ Pocket WiFi ก็ยังไม่น่ากังวล
2. คนที่ต้องกังวลคือคนที่ใช้ Wireless Access Point ในสถานที่ที่ควบคุมไม่ได้ เช่นที่ทำงาน (เวรล่ะ) วิธีแก้คือเดินไปหา Access Point แล้วนั่งทำงานใกล้ๆ ให้สัญญาณแรงๆ เข้าไว้ (ทำได้เรอะ)
แก้ไข: ไปนั่งกินเนื้อย่างคุยกับคนที่อ่าน Paper นี้ครบแล้ว สรุปว่าถ้า Attacker ตั้งใจโจมตีรายคน เอาเสาส่งแบบ Beam ไปยิงเพื่อเปลี่ยน Channel ทำ Man-In-The-Middle Rouge Access Point ได้ ดังนั้นอยู่ใกล้ Access Point ก็อาจไม่ช่วย
3. ส่วนคนที่ใช้ Public WiFi แบบไม่รู้สึกตะขิดตะขวงใจ ไม่ได้ผลกระทบอะไรเพิ่ม ไม่ปลอดภัยยังไง ก็ไม่ปลอดภัยเท่าเดิม
ทางแก้ ก็ Update WPA2 Patch ของ Wireless LAN Adapter ที่เครื่องตัวเอง ส่วนมือถือถ้าไม่มี WiFi Patch หรือ Update ออกนอกบ้านก็ 3G/4G โลด

Update: Ubuntu ออก WPA Package Update แล้วนะ แก้ Program ชื่อ wpa_supplicant (2.4-0ubuntu6.2) อย่าลืม Update กัน

KRACK Attacks: Bypassing WPA2 against Android and Linux

07 ตุลาคม 2560

Security ใน DevOps ต่างจาก DevSecOps อย่างไร

มีคำถามเรื่อง DevSecOps ว่า Dev กับ Ops ก็มี Security อยู่แล้วไม่ใช่หรือ ทำไมต้องมี DevSecOps เพิ่มขึ้นมา คำตอบของคำถามแรกคือทั้งใช่และไม่ใช่ ส่วนคำถามหลังต้องอธิบายเพิ่มเติม
ในการทำ DevOps ในส่วน Security ที่ควรจะมีอยู่แล้วด้าน Dev ก็คือเรื่องของ Secure Design และ Secure Coding ซึ่งเป็น Practice ที่จำเป็นต้องมีในการ Implementation เช่นการปฏิบัติตาม OWASP Application  Security Verification Standard เป็นต้น อีกด้านคือฝั่ง Ops ที่ควรจะมีโดยพื้นฐานก็เช่นการทำ Hardening หรือ Secure Deployment Process เป็นต้น
แล้ว DevSecOps มาช่วยอะไร
ในการพัฒนา Software นั้นถ้าอ้างอิงตาม Microsoft Security Development Lifecycle (SDL ดู https://www.microsoft.com/en-us/sdl/) การทำ Automation ของ DevSecOps นั้นอยู่ที่ Implementation และ Verification
Microsoft Security Development Lifecycle

ในขั้นตอนหลังจาก Implementation จะต้องมีการทำ Security Practice ก็คือตรวจสอบว่าใช้เครื่องมือในการพัฒนา (Tool Chain) และ Library ที่ได้รับการอนุมัติแล้วหรือเปล่า รวมทั้งการทำ Static Code Analysis  เป็นต้น นี่เป็นขั้นตอนก่อนการ Compile และ Build เพื่อทำ Automate Testing
ขั้นตอน Verification ประกอบด้วยการทำ Dynamic Analysis เช่นทำ Vulnerability Assessment Scanning ทำ Fuzz Testing โดยการลองป้อนข้อมูลที่ไม่อยู่ในรูปแบบที่ถูกต้อง (Malformed Data) เพื่อทดสอบว่าแอพพลิเคชั่นสามารถจัดการกับข้อมูลเหล่านี้ได้โดยไม่ก่อให้เกิดปัญหาทางด้าน Security ไปจนถึงการทํา Penetration Testing ซึ่งขั้นตอนนี้ควรทำหลังจากทำ Automate Testing เสร็จเรียบร้อยแล้ว และก่อน Deployment
นอกเหนือไปจากการตรวจสอบ Security แล้วยังมีส่วนที่ต้องทำการตรวจสอบเพิ่มเติมก็คือการตรวจสอบเพื่อเป็นไปตามการกำกับดูแล (Compliance) สิ่งต่างๆเหล่านี้รวมทั้งหมดแล้วไม่ได้ถูกเขียนไว้ในกระบวนการการทำ DevOps แบบที่ทำโดยทั่วไป
สำหรับท่านที่สนใจสามารถหาอ่านรายละเอียดได้จากเอกสาร White Paper ตามลิงค์ด้านล่าง
http://www.devseccon.com/wp-content/uploads/2017/07/DevSecOps-whitepaper.pdf

07 มิถุนายน 2560

Software Security Requirement Guideline กับการปล่อยไก่ของผม

เรื่องเล่ายามดึก
ตอนเข้ามาเกียรตินาคินใหม่ๆ ได้เขียน Software Security Requirement Guideline ฉบับหนึ่งเพื่อให้ทาง Development Team และ Vendor ทำตาม โดยอ้างอิงจากเอกสารของ OWASP ฉบับหนึ่ง (ซึ่งเดี๋ยวจะบอกทีหลัง) เป็นหลัก โดยมีการปรับแก้เพิ่มเติมบางอย่างตาม IT Policy ของธนาคาร และ Industrial Standard และ Regulation เช่น PCI-DSS หรือ Best Practice ของธนาคารแห่งประเทศไทยเข้าไป (ซึ่งไม่ได้มากมายเพราะส่วนใหญ่ของ OWASP จะดีกว่าอยู่แล้ว)
หลังจากนั้นเอกสารฉบับนี้ก็มีการรวมร่างกับ Software Architecture Requirement กลายเป็น Software Security and Architecture Guideline ล่าสุดคือ Version 4 และผมก็ไม่ได้เขียนเองแล้ว แต่เป็นคน Review
ตัดกลับมาเมื่อคืนวาน น้องในกลุ่ม OWASP บอกว่าหาคนไปพูดเรื่อง
ASVS ในงาน Thailand Security Day อะไรสักอย่างที่ ETDA วันที่ 26 มิถุนายน ผมก็บอกว่า ASVS คืออะไร ไม่เคยได้ยิน สักพักก็มีการส่ง Link ของเอกสารมาให้ เปิดไปดูก็เห็นเขียนว่า OWASP Application Security Verification Standard 3.0.1 (July 2016) เราก็อืม มันเป็นตัวย่อนี่เอง นั่งอ่านไปสักพักก็รู้สึกว่าคุ้นๆ แฮะ นึกไปนึกมาก็จำได้ว่าเราเคยใช้รายการในเอกสารฉบับนี้เขียน Software Security Guideline ของธนาคาร กลับไปเช็คดู เฮ้ย เราใช้ Version 2.0 เป็นต้นฉบับนี่นา
ด้วยอารมณ์ที่คิดว่าต้อง Update รายการให้ทันสมัยเลยส่ง Link ไปให้น้องในทีมที่ดูแลเอกสารต่อ บอกว่าเราต้อง Update ให้กับเอกสาร Software Security and Architecture Guideline แล้วล่ะ
วันนี้น้องในทีมมาบอกว่า พี่ ผมใช้เอกสารของ OWASP ฉบับนี้มาแก้เอกสารของเราในเวอร์ชันปัจจุบันแล้วนะ พี่เป็นคนรีวิวเองด้วย
ไก่วิ่งเต็มที่ทำงาน จับแทบไม่ทัน