ช่วงนี้ด้วยพลังของ Bitcoin maximalist แห่ง ChalokeDotCom และด้วยอิทธิพลของการพยายามเข้าใจ Proof of Work ผ่าน Game theory แบบง่ายๆ ทำให้เกิดความอินที่จะรู้ต่อและลองเอาสิ่งที่รู้ไปใช้กับปัญหารูปแบบอื่น ในขณะที่ม่านของอิทธิพลนี้ยังคงฟุ้งอยู่ในหัวและรายล้อมรอบตัว ผมก็ไปเจอกับประเด็นที่น่าสนใจและมีความใกล้เคียงกันจาก HITBSecConf 2021 ซึ่งพึ่งจัดไป ประเด็นดังกล่าวอยู่ในหัวข้อ Security Technology Arms Race 2021 โดย Mark Dowd ซึ่งพูดถึงพัฒนาการของ Offensive และ Defensive ใน Cybersecurity และมีบางส่วนที่พูดถึงมูลค่าและราคาของทั้งการพัฒนาในทั้งสองฝั่งด้วย

บล็อกนี้จึงเกิดขึ้นมาด้วยจุดประสงค์หลักสองอย่าง จุดประสงค์หลักอย่างแรกของมันคือการใช้เป็นที่สรุปความเข้าใจโดยใช้ภาษาเขียนเพื่อให้เกิดการจดจำและเข้าใจรายละเอียดของเนื้อหาอย่างมากพอที่จะเอาไปกร่อนใช้ในภาษาพูดต่อ และจุดประสงค์คือการถ่ายทอดเนื้อหาในประเด็นนี้ออกมาเป็นภาษาไทย โดยหวังว่าจะมีใครซักคนมาอ่านแล้วได้ประโยชน์ในการเข้าใจปัจจุบันและเห็นอนาคตที่จะเกิดขึ้นต่อ

สำหรับที่สนใจฟังต้นฉบับ HITBSecConf มีการอัปโหลดเซสชันนี้เอาไว้ที่ Youtube พร้อมกับสไลด์ที่ใช้ในการบรรยายด้วย

Asymmetry

เนื้อหาส่วนแรกของการบรรยายนั้นพูดถึงความไม่สมมาตรระหว่าง Offensive และ Defensive เป็นหลัก ความไม่สมมาตรตั้งแต่เริ่มต้นส่งผลให้เกิดความได้เปรียบและเสียเปรียบระหว่างปัญหาและการแก้ปัญหา ระหว่างการโจมตีและการป้องกันหรือในมุมอื่นๆ

การมองหาความไม่สมมาตรนั้นไม่จำเป็นไปต้องมองไปที่ไหนไกล ด้วยโลกที่เชื่อมต่อกันอยู่ในทุกวันนี้ เทคนิคการโจมตีถูกคิดค้นมาอย่างต่อเนื่อง บางครั้งเกิดขึ้นด้วยต้นทุนที่ต่ำและการเปลี่ยนแปลงที่เล็กน้อยแต่กลับส่งผลที่มากกว่าเท่าตัวได้ ในขณะที่การพัฒนาเทคนิคที่มีต้นทุนสูงก็ส่งผลที่สูงมากกว่า แค่เพียงการมองผ่านอย่างไม่ใส่ใจในรายละเอียดเท่าไหร่นัก เราจะเกิดภาพได้อย่างไม่ยากว่าเทคโนโลยีในฝั่ง Offensive นั้นเป็นผู้นำ และเทคโนโลยีในฝั่ง Defensive นั้นเป็นผู้ตาม ส่งผลให้การนำเทคโนโลยีไปใช้ก็สร้างภาพที่คล้ายคลึงกันระหว่างผู้นำและผู้ตาม

Mark พูดถึง 6 ปัจจัยที่สำคัญซึ่งสร้างความไม่สมมาตรนี้ให้เกิดขึ้นและคงอยู่ต่อ ผมขอยุบประเด็นบางส่วนมาเนื่องจากหากอธิบายในมุมของผมแล้ว มันเป็นประเด็นที่ใกล้เคียงกันและสามารถจับกลุ่มมาอยู่ด้วยกันได้ ปัจจัยดังกล่าวมีดังนี้

  1. Security ไม่ได้เป็นคุณสมบัติที่ถูกคำนึงถึงเป็นอันดับแรกๆ ในการออกแบบและพัฒนา ในขณะที่เทคโนโลยีที่เกิดขึ้นมาใหม่ยังคงเพิกเฉยต่อแนวคิดของกลยุทธ์และสมมติฐานเพื่อเพิ่มความปลอดภัยจาก Defensive
  2. Security boundary ไม่ได้ถูกกำหนดขึ้นมาหรือถูกกำหนดขึ้นมาอย่างไม่เหมาะสม ส่งผลให้เมื่อเทคโนโลยีเปลี่ยน Security boundary ไม่สามารถที่จะขยับตามได้
  3. การวิจัยเพื่อเพิ่มความปลอดภัยโดยส่วนใหญ่ในสมัยก่อนอย่างเป็นสิ่งที่ใหม่และยังไม่มีประสิทธิภาพ เช่น การศึกษารูปแบบของช่องโหว่, การทำ Static analysis และ Decompilation, แนวคิดของการหาช่องโหว่แบบ Fuzzing หรือการปรับใช้ Best practice ในการพัฒนาซอฟต์แวร์
  4. สภาพแวดล้อมของ Defensive เริ่มต้นและเติบโตด้วยอัตราที่ไม่สามารถชดเชยผลกระทบของ Offensive ได้ ตัวอย่างเช่น แนวคิดของ Patch management ซึ่งในบางเงื่อนไขนั้นเป็นเรื่องที่ยากและจะยากยิ่งขึ้นหากปริมาณระบบที่ต้องอัปเดตนั้นมากขึ้น หรือความสามารถในตรวจจับและระบุหาการโจมตีที่มีความซับซ้อนด้วยเช่นกัน
  5. การพัฒนา Defensive ขาดซึ่งมุมมองแบบ Offensive นั้นทำได้ยาก ดังนั้นประสิทธิภาพของ Defensive จำเป็นต้องพึ่งพาผู้ซึ่งมีความเข้าใจใน Offensive อย่างถ่องแท้เสียก่อน

เราอาจจะเคยได้ยินว่าฝั่ง Offensive แค่ถูกเพียงครั้งเดียวก็ชนะแล้ว ในขณะที่ฝั่ง Defensive นั้น ชัยชนะจะต้องเกิดจากการไม่ผิดเลยซักครั้งไปตลอดเท่านั้น

ด้วยแรงจูงใจที่เหมาะสม ความง่ายที่จะทำให้เกิดขึ้นจริงและผลกระทบที่ต่ำหากลงมือทำจริงอย่างดีพอ ความไม่สมมาตรของ Offensive และ Defensive จึงเกิดขึ้นและเปลี่ยนแปลงไปในทาง Defensive นั้นเสียผลประโยชน์มากกว่าในที่สุด

Defensive Goals

แม้จะเริ่มออกตัวช้ากว่า แต่ Defensive ก็มาในทิศทางที่มีประสิทธิภาพและมีอัตราเร่งที่ดีขึ้นอยู่เสมอ เมื่อพูดทิศทางที่มีประสิทธิภาพที่ Defensive กำลังพัฒนาไป Mark จัดกลุ่มเป้าหมายที่ Defensive กำลังมุ่งไปหาออกเป็น 3 กลุ่มได้แก่

  1. ทำให้การโจมตีโดยใช้เครื่องมือ Offensive นั้นแพงขึ้น
  2. จำกัดและควบคุมความเสียหายที่เกิดจากการโจมตี
  3. ระบุหาการโจมตีที่สำเร็จไปแล้ว

ในประเด็นแรกที่มีเป้าหมายให้การโจมตีมีราคาแพงขึ้น เนื่องจากพื้นเพของ Mark นั้นคือ Vulnerability research and development การพูดถึงราคาจึงเกิดขึ้นในมุมของการช่องโหว่และการนำมาใช้เพื่อโจมตีเป็นหลัก ราคาในส่วนนี้ประกอบไปด้วยราคาอีก 3 ส่วนได้แก่ราคาหรือมูลค่าที่นำไปสู่การค้นพบ (Discovery cost), ราคาหรือมูลค่าที่นำมาสู่การพัฒนา (Development cost) และราคาหรือมูลค่าที่ทำให้การใช้ช่องโหว่เพื่อโจมตีนั้นยังคงสามารถเกิดขึ้นได้ (Maintenance cost)

ลองเจาะเข้าไปในราคาแต่ละส่วน ราคาในส่วนแรกอย่าง Discovery cost มีคุณลักษณะที่น่าสนใจ คือคุณลักษณะที่ราคาหริอมูลค่าจะสูงขึ้นในการค้นพบช่องโหว่แรก หลังจากนั้นราคาหรือมูลค่าจะลดลงเนื่องจากการนำรูปแบบหรือวิธีการมาใช้ซ้ำ

การทำให้ราคา มูลค่าหรือทรัพยากรที่ต้องใช้สูงขึ้นจนทำให้การค้นหาเป็นไปได้ยากจึงเกิดขึ้นในลักษณะ เช่น โครงการ fuzzing ขนาดใหญ่โดยผู้พัฒนาซอฟต์แวร์เองหรือการ fuzzing โครงการโอเพนซอร์สซึ่งทำให้รูปแบบของช่องโหว่ที่มีลักษณะคล้ายกันถูกค้นพบก่อน และบีบให้การค้นหาช่องโหว่ในซอฟต์แวร์เดียวกันภายหลังมี Discovery cost ที่สูงขึ้น

การทำให้ช่องโหว่ไม่สามารถถูกใช้เพื่อโจมตีได้โดยการใช้กลไกทางเทคนิคก็เป็นส่วนหนึ่งซึ่งส่งผลให้ช่องโหว่ที่ถูกค้นพบนั้นไม่สามารถนำไปทำอะไรต่อได้เช่นกัน

ถัดมากับ Development cost หรือราคา มูลค่าและทรัพยากรที่ถูกใช้เพื่อการพัฒนาโค้ดสำหรับช่องโหว่นั้นๆ ความพยายามเพื่อเพิ่ม Development cost เกิดขึ้นในลักษณะ อาทิ การบังคับทำ Code signing หรือฟีเจอร์อย่าง ASLR ที่ทำให้โค้ดสำหรับโจมตีช่องโหว่จะต้องถูกเพิ่มด้วยเทคนิคสำหรับหลบหลีกกลไกในการป้องกัน ในบางกรณีนั้นเทคนิคที่ช่วยสนับสนุนให้โค้ดสำหรับโจมตีช่องโหว่สามารถทำงานได้อย่างปกติแทบจะกลายเป็นสิ่งไร้ค่าและส่งผลให้ Development cost นั้นเพิ่มสูงเป็นอย่างมากสำหรับฝั่ง Offensive

Maintenance cost เป็นประเด็นที่ถูกพูดถึงน้อยที่สุดแต่อย่างไรก็ตามมันก็กำลังถูกจัดการด้วยกลไกของการอัปเดตซอฟต์แวร์อย่างบ่อยครั้งซึ่งส่งผลให้อายุของช่องโหว่นั้นสั้นลงและเพิ่ม Maintenance cost ไปในตัว

ผลลัพธ์ของการเพิ่มขึ้นของราคา มูลค่าและทรัพยากรเพื่อให้การพัฒนาโค้ดสำหรับช่องโหว่ให้สามารถใช้งานได้จริงและตอบสนองความต้องการของผู้ใช้บริการส่งผลอย่างเห็นได้ชัดต่อตลาดที่ซื้อขายช่องโหว่

ประเด็นหนึ่งที่น่าสนใจแต่ผมไม่พบว่าถูกพูดถึงในการบรรยายนี้คือการโครงการ Bug bounty ซึ่งผมเชื่อว่าหากทำอย่างถูกต้องแล้วมันจะมีส่วนช่วยสำคัญ โครงการอย่าง Bug bounty นำเสนอ profit ซึ่งสามารถดึงผู้เล่นในตลาดเหล่านี้มาหาตนได้ด้วยคอนเซ็ปต์พื้นฐานอย่างการให้รางวัล

บทบาทของโครงการ Bug bounty นั้นภายใต้เงื่อนไขและรางวัลที่เหมาะสม มันสามารถถูกใช้เป็นเครื่องมือของผู้ผลิตซอฟต์แวร์สำหรับบทของการเป็นพระเอก (ให้รางวัลหากยอมทำตาม) โดยไม่จำเป็นต้องเล่นเป็นบทตัวร้ายซึ่งอาจสร้างผลกระทบในแง่ร้ายได้มากกว่า (ลงโทษหากไม่ยอมทำตาม) และปล่อยให้หน้าที่ของการบีบบังคับนั้นเกิดขึ้นจากสภาพแวดล้อมที่กดดันให้ Cost ทุกอย่างเพิ่มขึ้นเอง

มาต่อกับประเด็นที่สองในเรื่องของการจำกัดและควบคุมความเสียหายที่เกิดจากการโจมตี กลไกสำคัญที่ในกลุ่มนี้ทั้งหมดคือกลไกเชิงเทคนิคที่ถูกเพิ่มหรือเสริมไปในระบบปฏิบัติการเพื่อทำให้การโจมตีช่องโหว่นั้นมีโอกาสสำเร็จน้อยลง จากการใช้เทคนิคไม่กี่เทคนิคเพื่อให้การโจมตีสำเร็จถูกเปลี่ยนเป็นการต้องหาช่องโหว่เพิ่มเพื่อให้ช่องโหว่ของเรานั้นทำงานได้ปกติเนื่องจากกลไกด้านความปลอดภัยปิดช่องทางที่เป็นไปได้เดิมออกทั้งหมด

Mark ยกตัวอย่างผ่านช่องโหว่ในเว็บเบราว์เซอร์ของ iPhone ด้วยเทคโนโลยีปัจจุบัน Attack surface ที่เป็นไปได้ถูกจำกัดให้อยู่ในลักษณะของ Phishing ที่เหยื่อมีโอกาสที่จะไม่คลิกหรือเปิดลิงค์ ถัดมาแม้ผู้ใช้งานจะเปิดลิงค์ที่มีโค้ดสำหรับโจมตีช่องโหว่อยู่ในเว็บเพจ ผู้โจมตีก็ได้สิทธิ์ที่จำกัดในการเข้าถึงหน่วยความจำและไม่มีสิทธิ์ในการเอ็กซีคิวต์โค้ดอื่น ความพยายามในการใช้โปรเซสอื่นในการเอ็กซีคิวต์โค้ดผ่านเทคนิค Process injection ก็ถูกจำกัดด้วยฟีเจอร์อย่าง Page Protection Layer (PPL) และท้ายที่สุดคือความยากในการฝังตัวและทำให้การเข้าถึงด้วยช่องโหว่นั้นยังคงอยู่รอดหากเป้าหมายมีการรีสตาร์ทอุปกรณ์

เป้าหมายสุดท้ายของ Defensive คือการตรวจจับและระบุหาการโจมตีที่สำเร็จ เราต่างรู้กันว่านี่คือไม้เบื่อไม้เมาของชาว Defensive อยู่เสนอทั้งในเรื่องประสิทธิภาพของวิธีการ อย่างไรก็ตามในช่วงไม่กี่ปีที่ผ่านมา เราเห็นความพยายามหลายอย่างในการเผยแพร่และแบ่งปันข้อมูลเพื่อให้การตรวจจับและระบุหาเป็นไปอย่างรวดเร็วและมีประสิทธิภาพมากยิ่งขึ้น ยกตัวอย่างเช่น โครงการ 0-days In-the-Wild ของ Project Zero และการพัฒนาด้านศักยภาพของ APT hunting team

Future

เมื่อเครื่องมือและศักยภาพในเชิง Offensive ถูกชะลอจากความก้าวหน้าของ Defensive คำถามที่สำคัญต่อจากนี้คือแล้วมันจะเป็นอย่างไรต่อ

Mark สรุปไว้ในส่วนท้ายของการบรรยายหากอัตราเร่งของการพัฒนาทางด้านกลไกในการยับยั้งและป้องกันยังคงดำเนินไป ช่องโหว่ที่ถูกค้นพบจะถูกทำให้ยากขึ้นในการนำมาใช้งานและจะส่งผลต่อกระบวนการอื่นๆ ก่อนที่จะมีการพัฒนาโค้ดสำหรับโจมตีช่องโหว่ ในสถานการณ์นั้นหาก Defensive มี Telemetry ที่สิทธิ์สูงกว่าโค้ดหรือเครื่องมือของ Offensive การตรวจจับจะมีโอกาสประสบความสำเร็จสูงขึ้นตาม

ด้วย Mitigation ที่เกิดขึ้น ช่องโหว่ในกลุ่ม Memory corruption จะถูกลดความสำคัญและจะเกิดการโอนถ่ายความสำคัญนั้นไปยังช่องโหว่ในกลุ่มอื่นแทนที่การระบุช่องโหว่ การพัฒนาโค้ดสำหรับโจมตีและผลกระทบที่ช่องโหว่สามารถสร้างขึ้นได้นั้นมีภาพที่สวยงามกว่า ตัวอย่างของช่องโหว่ในกลุ่มที่น่าสนใจ เช่น ช่องโหว่ที่มีที่มาจากปัญหาในฝั่ง Cryptography จากช่องโหว่ Remote code execution ใน Microsoft Exchange ที่ถูกค้นพบโดย Orange Tsai หรือช่องโหว่อย่าง ZeroLogon นอกเหนือจากช่องโหว่ในฝั่ง Cryptography แล้ว ช่องโหว่ของเทคโนโลยีเว็บและช่องโหว่ในโปรโตคอลก็กำลังได้รับความสนใจสูงขึ้นเช่นเดียวกัน