สรุปเนื้อหางาน MiSSConfSP7

Bank Eakasit
6 min readJun 21, 2023

--

งาน MiSSConf เป็นงานสัมมนาฟรี แบ่งปันความรู้ด้าน IT Security รอบนี้จัดผ่านไปเมื่อวันเสาร์ที่ 10 มิถุนายน 2023 ที่มหาวิทยาลัยมหิดล (ราชวิถี)

บทความนี้เป็นบทความสรุปเนื้อหาจากการฟังภายในงานของผู้เขียนเอง อาจมีไม่ครบ ผิดพลาดประการใด หรือการเลือกใช้คำอาจจะไม่ตรงกับคำพูดจาก speaker ต้องขออภัยด้วยครับ (speaker ไม่รับผิดชอบฉันใด ผมคนสรุปมาอีกทีก็ไม่ขอรับผิดชอบฉันนั้น) ส่วนรูปกับ slide ผมจะพยายามเติมเข้ามาเรื่อยๆเมื่อ speaker มีการแจกครับ

ก่อนลงเนื้อหา ขอบคุณ TechTalkThai https://www.techtalkthai.com/ ที่ให้โอกาสส่งผมไปเป็นตัวแทนรับฟังเนื้อหางานครับ พี่ก็ใจดีให้ผมไปฟังแบบไม่ต้องทำการบ้านอะไรส่ง แต่ผมก็ลองบังคับให้ตัวเองไปฟังงานในมุมคนเขียนข่าวดู พบว่า… สอบตก 555 เข้า session แรกไม่ทัน (กำ) ซึ่งถือว่าสำคัญมาก แล้วก็ไม่ได้ถ่ายรูป sponsor ทั้งหลายมาด้วย ไม่เป็นไร อันนี้เป็นสรุปเนื้อหา knowledge ล้วนๆไปครับผม

ปล. ขอบคุณพี่เข้ที่ทักครับ ผมข้าม session พี่เมธไปเลย T_T จดไว้หมดแล้ว แต่น่าจะพลิกกระดาษข้ามหน้า เติมให้เรียบร้อยละครับ

ขอบคุณ sponsor ทุกท่านด้วยนะครับ

รูปจากเพจ Association for Interdisciplinary Knowledge Exchange

AI Adoption in Cyber Defense

เริ่มจาก Mr. Phusit Chevakanit ที่เป็นทีม R&D จาก CYBER ELITE มาเล่าว่ามีการเอา AI มาใช้ในระบบการป้องกันภัย Cyber อย่างไรบ้าง เริ่มจากการพูดถึงการนำ AI มาใช้เนี่ย ส่วนใหญ่ก็มีเป้าหมายเหมือนกัน คือ save cost, improve performance (ความแม่นยำ ความถูกต้อง), customer experience ที่ดีขึ้น ส่วนปัญหาก็จะคล้ายๆกัน เช่น ไม่มีตังไว้พัฒนา, คนที่มีความสามารถด้านนี้มีไม่เพียงพอ เป็นต้น

สำหรับการนำมาใช้ใน Cyber Defense มีสองด้าน คือ Proactive และ Reactive ครับ และแบ่ง key ออกเป็นทั้งหมด 6 กลุ่ม คือ Thread Detection, Thread Response Time, New Threat, Staffing capacity and expertise, Large Volume of Alerts, และ How to Manage สำหรับใน session นี้จะยก use case เฉพาะกรณี UEBA และ NLP มาพูดเท่านั้น ซึ่งเป็นการนำ ML แนว Anomaly Detection มาใช้ใน Threat Detection

สำหรับ UEBA (User & Entity Behavior Analysis) เป็นการ detect anomaly แบบ unsupervise ใช้ท่า isolation forest ข้อดีคือไม่จำเป็นต้องลงมือไป classify ข้อมูลเอง ใช้งานได้ทันที ตัวอย่างของข้อดี เช่น

  • Rule-based แบบเดิม: ห้าม login เกิน 10 ครั้ง ทำได้แค่นี้
  • UEBA: ดูจากข้อมูลที่ผ่านมา ดูความผิดปกติของการ login ของ user คนนั้นๆ อาจจะ plot แบบ 2D ดูทั้ง time และ location ก็ได้ ก็จะเห็นชัดเจนว่ามีจุดไหนผิดปกติ วิธีนี้ดีกว่า Rule-based มาก เช่น user ใช้งานบางคนอาจจะต้องใช้ VPN ตลอดเวลา ทำให้เห็นว่ามีการ login จาก 2 ตำแหน่งพร้อมกัน การใช้ UEBA จะสามารถเข้าใจเคสแบบนี้ได้

สำหรับ NLP (Natural Language Processing) เหมาะสำหรับ issue ประเภท recurring detection ค่อยๆ train model ด้วยการเปิด ticket incident วิธีนี้จะทำให้ไม่ต้องใช้ข้อมูลจำนวนมาก ค่อยๆเพิ่มได้

ทั้งนี้ทั้งนั้น วิธีการทั้งหมดที่เล่ามา เป็นเพียงเวอร์ชัน simplified ของทางทีมเท่านั้น ในการใช้งานจริง ยังมีรายละเอียดอื่นๆอีก เช่น เคส UEBA ป้องกัน data poisoning (เช่น กรณี user โดน compromise ไปก่อนแล้ว) ด้วยการเปรียบเทียบกับ user กลุ่มด้วย เป็นต้น

Data Breach Management Strategies for SMEs to Enterprises

พูดโดย Ms. Kullatee Boonsiri จาก Green Grapes มาเล่าประสบการณ์และคำแนะนำจากสิ่งที่เจอจากลูกค้า เนื้อหาใน session นี้จะเป็นแนวกว้างๆภาพรวม ไม่ได้ลง technical ในจุดย่อย คำถามที่เจอจากลูกค้าบ่อยมาก เช่น เราป้องกันเท่านี้เพียงพอหรือยัง ISO ตัวใหม่จำเป็นแค่ไหน คำแนะนำคือให้ยึดหลักการ People, Process และ Technology ซึ่งสามตัวนี้จะมีแนวทางในการพัฒนาแตกต่างกัน ให้เอาแนวทางเหล่านี้ไปจับกับปัญหาต่างๆเพื่อแก้ไข

ความแตกต่างของ SME และ Enterprise มีเยอะมาก เช่น Data Volume, Infrastructure, Scalability and Flexibility, Budget/Resources, Data Governance, Data security, Compliance and Regulation ซึ่งความแตกต่างเหล่านี้เป็นสาเหตุที่ไม่มี one answer สำหรับทุกกรณี แต่ละบริษัทต้องหาท่าที่เหมาะสมกับตัวเอง

วิธีการแก้ปัญหาให้เหมาะกับตัวเอง ให้เริ่มจาก WHY, WHAT, WHERE, WHEN, HOW, WHO โดยสำหรับ session นี้จะพูดถึงเป็นคู่ๆแทน

WHY&WHAT? ให้

  1. List all compliances ที่เกี่ยวข้องทั้งหมด ทั้งกฎหมาย regulation และ policies
  2. List core data (ทำ data inventory)
  3. Classify data เหล่านั้น

WHERE&WHEN? สิ่งที่ตอบโจทย์ดีที่สุดคือ Data Risk Assessment โดยการ identify threats ว่ามีอะไรบ้าง อาจจะดูจาก channels และ threat vectors ต่างๆ หรือแบ่งย่อย channels เหล่านั้นได้อีก

  • Data at rest เช่น File, database, harddisk, removable devices, etc.
  • Data-in-motion เช่น Email, ข้อมูล Web, Network, Cloud

HOW&WHO? ค่อยเป็นขั้นตอนในการเอาเนื้อหาก่อนหน้ามาประกอบกันเป็นวิธีป้องกันเป็นตาราง ค่อยๆเติมลงไปเรื่อยๆ ถ้า enterprise resource เยอะก็เติมง่ายหน่อย

ถ้า SME ก็เติมส่วนที่สำคัญและทำได้ไปก่อน จะเห็นว่านอกจากส่วนที่เป็นสีเทาแล้ว (ค่าใช้จ่ายสูงสำหรับ SME) เมื่อเทียบกับ enterprise ก็มีหลายกล่องที่เปลี่ยนสีด้วย (ความสำคัญเทียบราคาไม่เท่าเดิม)

Securing & Hacking LINE OA Integration

Slide: https://www.slideshare.net/pichayaa/securing-and-hacking-line-oa-integration

พูดโดย Mr. Pichaya Morimoto จาก Siam Thanat Hack (STH) มาเล่ารายละเอียดของ security ของการใช้งาน LINE Official Account (OA) ครับ เริ่มจากยกตัวอย่าง MSN รุ่นเก่าว่ามันก็มีช่องโหว่มากมาย มีทั้ง client side, server side และ user error พอมาสมัยใหม่ ผู้คนย้ายมาใช้ LINE กันเยอะขึ้น การพิจารณาช่องโหว่ก็ยังคงเหมือนเดิมคือ client side, server side และ user error

คำแนะนำ ให้ดู architecture ภาพรวมก่อน มีอะไรที่เราเขียนเอง มีอะไรที่ LINE offer ให้ การดูให้ละเอียดกว่านั้น คือดูตาม feature ของ LINE เช่น messaging API, LINE Login, LIFF เราได้ใช้ตัวไหนบ้าง ก็ต้องดูตัวนั้นด้วย ว่ามันมีส่วนประกอบอะไรบ้าง

Attack surface แบบตรงไปตรงมา มี 5 จุด

  1. Attack payload เข้า webhook
  2. จังหวะ webhook — อาจะโดนยิงเข้า webhook ตรงๆไม่ผ่าน server LINE
  3. กรณียิง API LINE เพื่อขอ data เพิ่ม — channel token leak หรือปล่าว
  4. LINE LIFF
  5. Back office ต่างๆ ที่เกี่ยวข้องกับระบบ

สำหรับข้อแรกเนี่ย (chat message) ให้คิดเหมือน web app เลยครับ คือข้อมูลที่เข้ามาจาก user ควรเป็น untrusted ไม่ควรเอาไปใช้งานตรงๆโดยไม่ผ่านการกรองหรือพิจารณาก่อน ส่วนข้ออื่นๆ คำแนะนำที่สรุปได้คือ ควรทำตาม best practice ที่ LINE แนะนำครับ อย่าคิดเองเออเอง ซึ่งยุคนี้นอกจาก document เองก็มี LINE developer มาเขียนบทความอธิบายวิธีการใช้งานอย่างถูกต้องอยู่ หาตาม Google ก็ได้ หรือกลุ่ม Facebook ก็มีครับ

Using Signed SSH Certificate for Remote Access with HashiCorp Vault

Slide: https://www.dropbox.com/s/d1bcbqqz1n5b9a9/exported-SSH_Secrets_Engine.pdf?dl=0

พูดโดย Mr. Damrongsak Reetanon จาก MFEC เป็นการอธิบาย alternative solution ที่ดีกว่าเดิม สำหรับการจัดการกับ SSH keys ซึ่งโดยปกติเราต้อง add pub.key เข้าไปในไฟล์ authorized_keys เพื่ออนุญาตให้เครื่องที่มี priv.key นั้น SSH เข้ามาใช้งานได้ แต่ความวุ่นวายจะเกิดขึ้นทันทีสำหรับระบบหรือองค์กรขนาดใหญ่ ที่มีคนใช้งานเข้าออกบ่อยๆ, กลุ่มของเครื่องที่ต้องการใช้งาน และวิธีการใช้งาน ของแต่ละคนที่ไม่เหมือนกัน เลยมาแนะนำท่าที่ดีกว่า คือการใช้ Certificate ในการ login และการใช้ feature ของ HashiCorp Vault ในการจัดการกับ Certificate นี้

เริ่มจากช่วงแรก เป็นการแสดงให้เห็นก่อนว่า การใช้ certificate ในการ SSH แทน authorized_keys เนี่ยมันเป็นยังไง ขั้นตอนการ sign ไปถึง SSH ต้องทำอะไรบ้าง แนะนำว่าดูจากเว็บของพี่จุ๊บเองเลยดีกว่าครับ https://blog.d8k.io/ssh-signed-cert-1/ ซึ่งข้อดีของการทำ cert เนี่ย คือ

  1. ระบุเวลา expire เองได้ ตั้งสั้นๆได้
  2. ระบุ function SSH ที่อนุญาตได้ (SSH login หรือ Port Forwarding, etc.)
  3. ระบุกลุ่มหรือ host ได้ (หรือเรียกว่า principle)

ทีนี้ถ้าต้องจัดการกับระบบ certificate เองเนี่ย มันวุ่นวาย และอาจจะผิดพลาดได้ง่าย ก็มี tool มาช่วยตรงนี้คือ vault สำหรับ session นี้แนะนำ HashiCorp Vault ครับ มี feature ช่วยเยอะแยะเลย เช่น เป็น secure secret storage, รองรับ dynamic secrets, รองรับ data encryption, รองรับ leasing and renewal รวมถึง revocation ด้วย พอใช้ระบบ vault แล้วเนี่ย จะแบ่งส่วนการทำงานก็ได้ เช่น กรณีมี admin หลายคนดูแลระบบคนละชุด ก็ใช้ policy ในการจัดการได้เช่นกัน ส่วนรายละเอียดเต็มเนี่ย แนะนำเหมือนเดิม https://blog.d8k.io/ssh-signed-cert-2/ (ละเอียดและถูกต้องกว่าผมจำมาเขียนใหม่แน่ๆครับ XD)

ตกลง(วงการ)หมอพร้อมหรือไม่พร้อม สำหรับภัยคุกคาม cybersecurity ในยุคนี้?

Slide: https://www.facebook.com/nawanan/posts/pfbid02fFzEnNkc47m91WJzUmaxQwoBvr9a4r31K3HD34eVEsk5Vx1iaeWrYiqAeg9wvh8kl

พูดโดย Nawanan Theera-Ampornpunt เป็นการเล่าเคส 9Near อันโด่งดังเนี่ยแหละ แต่เล่าในมุมมองของคนนอก (ไม่ใช่พนักงานสอบสวนและ insider) หลังจากที่ 9Near เอาข้อมูลตัวอย่างออกมา โดยเริ่มจากการทำ assessment เบื้องต้น ข้อมูลเป็นของบุคคลที่เกิดในปี 1990 ทั้งหมด พบว่าข้อมูล dirty มาก

  • คำนำหน้าชื่อเยอะ และหลากหลาย มีนายแพทย์ด้วย (ซึ่งเป็นคำนำหน้าวิชาชีพ จึงไม่น่าใช่ทะเบียนราษฎร์)
  • มีทั้ง นายแพทย์ และ นพ. (แปลว่าข้อมูลอาจจะมาจากหลายแหล่ง)
  • ไม่ clean — ชื่อกับคำนำหน้ารวมอยู่ด้วยกัน
  • โทรศัพท์อาจมีมากกว่าหนึ่ง
  • มีบางที่อยู่เป็นศูนย์ฉีดวัคซีน (จึงมีแนวโน้มสูงมากที่จะหลุดจากระบบที่เกี่ยวข้องกับวัคซีน)

(̶ถ̶̶้า̶ ̶h̶a̶c̶k̶e̶r̶ ̶ค̶น̶ไ̶ห̶น̶จ̶ะ̶ข̶า̶ย̶ข̶̶้อ̶ม̶̶ูล̶ ̶ช̶̶่ว̶ย̶ ̶c̶l̶e̶a̶n̶ ̶d̶a̶t̶a̶ ̶เ̶พ̶ิ̶̶่ม̶ ̶q̶u̶a̶l̶i̶t̶y̶ ̶ส̶ิ̶น̶ค̶̶้า̶ต̶ั̶ว̶เ̶อ̶ง̶โ̶ห̶น̶̶่ย̶)

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

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

How to use ChatGPT in Security Operation

พูดโดย Mr. Sumedt Jitpukdebodin จาก SecureD เป็นการพูดถึง use case จากการใช้งานจริงว่าหลังจาก ChatGPT ออกมาเนี่ย เอาไปใช้ทำอะไรบ้าง (ไม่ใช่พูดเรื่อง ML การทำงานของ ChatGPT นะ)

ผู้ใช้ต้องเข้าใจ promt ก่อน promt คือการสั่งงานตั้งต้น ให้มันรู้ว่ามันกำลังทำงานอะไร เราต้องการผลลัพธ์เป็นอะไร หลังจาก setup prompt เสร็จแล้วค่อยพิมพ์ข้อความต่อเป็น input ให้มันตอบ

สำหรับ use case ใน cybersecurity แบ่งเป็น 2 หัวข้อใหญ่ๆ คือ

  1. generic question
    - ถามเรื่องตำแหน่งงาน การเติบโตสายงานเป็นยังไง ต้องเรียนอะไรบ้าง
    - ถามเรื่องช่องโหว่ต่างๆ รู้จักตัวนู้นไหม ตัวนี้ไหม อธิบายหน่อย
    - ถาม tools ว่าปัญหาแบบนี้ใช้ tool ตัวไหนดี คำสั่งใช้งานเบื้องต้นมีอะไรบ้าง
  2. technical tasks
    - automation task เครื่องมือที่เอามาช่วยทำอะไรซ้ำๆ คืออะไร ใช้คำสั่งอะไรบ้าง
    - scripting ช่วยเขียนโค้ดเลย ซึ่งมันทำได้เยอะอยู่ เช่น ให้ช่วยเขียน NSE script (script สำหรับ NMap) หรือให้มันช่วยเขียน script burp ก็ทำได้ และทำได้ดีด้วย หรือเขียน SAST สำหรับ detect SQL injection ในขั้นตอน code review ก็ทำได้

สำหรับกรณีที่มันไม่ยอมตอบ ก็ใช้วิธีถามอ้อมๆแทน แทนที่จะถามว่า script ยิงยังไง ก็ถามว่า script ที่อันตรายควรป้องกันคืออะไร เป็นต้น ลองเปลี่ยนรูปประโยค เอาคำตรงๆเช่น “hack” ออก ไรงี้

อีกประโยชน์หนึ่งที่เอามาใช้ได้ดี คือช่วยเขียน report ครับ ในบางครั้งแค่ระบุ URL ที่มี payload บรรทัดเดียวให้มัน มันสามารถ generate report impact/description/mitigation ให้ครบเลย โหดมาก

เราต้องปรับตัว ต้องรู้จักการใช้งานและตามเทคโนโลยีให้ทัน อย่างเช่นโจทย์ CTF ก็ควรเช็คก่อนว่าไม่ใช่โจทย์ที่โยนลง ChatGPT แล้วได้คำตอบนะ

แต่ทั้งนี้ทั้งนั้น สำคัญมากๆ คือ มันตอบผิดได้ และมันไม่ได้ตอบลึกแบบผู้เชี่ยวชาญ ควรใช้เป็นแค่เครื่องมือประกอบการทำงาน ไม่ใช่เอามาทำงานแทนครับ

Biometrics Authentication: Can We Really Rely On?

Slide: https://www.slideshare.net/narudomr/biometric-authenticationpdf

พูดโดย Mr. Narudom Roongsiriwong หัวใจหลักๆอยู่ที่เรื่องความแตกต่างของ identification และ authentication ครับ วิธีของ Authentication เบื้องต้นที่ทุกคนรู้จัก มี 3 ท่า คือ What you know, What you have และ What you are ทั้งสามวิธีมีข้อดีข้อเสียแตกต่างกันชัดเจน อย่างกรณี What you have เนี่ย ข้อดีคือเปลี่ยนง่ายมาก issue token อันใหม่ให้ไปถือก็ได้แล้ว ส่วนกรณีของ What you are หรือ Biometric เนี่ยมีข้อเสียใหญ่คือ

  1. เปลี่ยนไม่ได้
  2. เสื่อมสลายตามกาลเวลา (คหสตผู้ฟัง: น่าจะ Tie-in ขายครีมได้นะเนี่ย)
  3. Exact match 100% ไม่ได้

อีกทั้ง biometric แต่ละตัวก็มี cost & accuracy ไม่เท่ากันด้วย การเลือกใช้จึงสำคัญ สำหรับกรณีของ face เนี่ย accuracy ต่ำ แต่ราคาถูก เมื่อพูดถึง accuracy ต้องเข้าใจก่อนว่า Biometric มี 2 โหมด คือ

  1. Identification ดูว่าหน้าคุณตรงกับใคร มี input มีข้อมูล N เทียบแบบ 1:N
  2. Verification รู้ว่าจะเทียบกับใคร แล้วเอาหน้าไปเทียบว่าใช่หรือไม่ เป็นการเช็คแบบ 1:1
(ยืมรูปมาจาก https://recfaces.com/articles/false-rejection-rate)

มีศัพท์เพิ่มเติมที่ต้องรู้จัก คือ False Acceptance Rate (FAR) และ False Reject Rate (FRR) สองค่านี้มันสวนทางกันเป็นกฎตายตัวเลย เป็นไปไม่ได้ที่จะทำให้สองตัวนี้มันต่ำพร้อมกัน สำหรับ Identity proof เนี่ย เราต้องให้ FAR ต่ำมากๆ จะได้ไม่ผิดคน ทำบ่อยๆนานๆได้จนกว่าจะถูก ในขณะที่ Verification เราหวังว่า FRR จะไม่สูงเกินไป ไม่งั้นก็ scan ไม่ผ่านซะที ไหนจะเรื่องโหมดที่ใช้อีก ดังนั้นหากจะใช้งาน 2 โหมด ก็ควรมี 2 model แยกกัน

ทีนี้ ก็มาดูว่า สมมติจะใช้งาน Biometric จริงๆแน่ มันมีคำแนะนำว่าอะไรบ้าง เอกสารที่ดีและแนะนำว่าควรอ่านประกอบคือ NIST SP 800–63B ครับ https://pages.nist.gov/800-63-3/ ถึงแม้ speaker จะหยิบเนื้อหาเอกสารมาพูดเลย แต่ผมคงสรุปจากที่ฟังซ้ำไม่ไหวเพราะอาจผิดพลาดได้ แนะนำว่าไปอ่านเองเลยดีกว่าครับ โดยสังเขปคือ เอกสารก็มีแนะนำข้อเสียของ biometric หลายเรื่อง และแนะนำว่าควรใช้เป็นการ authentication ประกอบกับวิธีอื่นเท่านั้น

Road to International Cybersecurity Championship

พูดโดย Mr.Piriya Muaithaisong & Mr.Tat Sangsomruang จากทีม MAYASEVEN ครับ มาเล่าประสบการณ์และแรงบันดาลใจในการไปแข่ง CTF งานต่าง ๆ ซึ่งตัวที่จะหยิบมาเล่าคืองานแข่ง ACSC (Asian Cyber Security Challenge) และ SECCON2019

ทุกคนมีการเรียนรู้ cybersecurity ที่แตกต่างกัน บางคนก็เริ่มจากอ่านหนังสือ (หนังสือ Hacking: The Art of Exploitation เล่มสีน้ำตาล ผมก็มีครับหลงซื้อมาตอน ม.ปลาย กว่าจะอ่านรู้เรื่องก็กำลังจะจบ ป ตรี 5555) ตัว CTF เป็นการ gamification ให้สนุกมากขึ้น ช่วยให้เกิด collaboration และ share ความรู้ภายในทีม อีกทั้งผลลัพธ์จากการแข่ง ผู้เล่นจะได้รับการยอมรับ และมี portfolio เป็นของตัวเองด้วย

ประเภทของ CTF มี 3 ประเภท คือ Jeopardy, Attack and Defense และ King of the Hill ส่วน category ในการเล่นมีหลากหลาย เช่น Forensics, Cryptography, Web application, Reverse Engineering และอื่นๆ แนะนำว่าสามารถฝึกจากเว็บต่างๆ เช่น HackTheBox, Root-me, OverTheWire และ Flare-on ได้หมด เลือกตามที่ชอบได้เลย อาจจะมีการเปิดโพยดูเฉลยบ้างเล็กน้อยกับข้อที่ทำไม่ได้เพื่อเรียนรู้ หากต้องการแข่ง CTF จริงๆ ก็สามารถหาได้จาก CTF time และ Pico CTF

ในส่วนของครึ่งหลัง จะเป็นการเอาโจทย์ CTF ของงาน ACSC และ SECCON2019 มาเหล่าให้ฟังครับ เป็นโจทย์ Template Injection และ Hardware Hacking ตามลำดับ เขียน step การแก้โจทย์ได้ออกมาละเอียด น่าสนใจไม่น้อยเลยทีเดียว ต้องขออภัยที่ไม่สามารถเรียบเรียงรูปให้ออกมาเป็นบทความได้ครับ

สรุป

งานดี อาหารอร่อย แอร์เย็นไปหน่อย เนื้อหาอิ่มความรู้กันไปทุกคน ถ้าใครไม่อยากพลาดที่จะฟังเนื้อหาแท้ๆจากเวทีด้วยตัวเองเลย ก็อย่าลืมติดตามข่าวสาร MiSSConf จากทาง TechTalkThai เพื่อจะได้ไม่พลาดลงทะเบียนปีหน้านะครับ

22 June 2023

--

--