Lecture 4: Non Malicious Software

Software Security

5 ตัวอย่างช่องโหว่ทาง Software จาก Open Web Application Security Top Ten

• Unvalidated input
• Buffer overflow
• Cross-site scripting
• Injection flaws
• Improper error handling

Software Quality vs Secuity

• Software quality and reliability: จะวัดว่าโปรแกรมมีข้อผิดพลาดบ่อยแค่ไหน
• Software security: ผู้บุกรุกจะกรอก Input กับ Code ที่มีช่องโหว่

Defensive Programming (Secure programming)

การเขียนโปรแกรม โดยคำนึงถึงทุกรูปแบบที่เป็นไปได้ และตรวจสอบทุก error ที่อาจจะเจอ (ต้องให้ความสนใจในทุกๆ ด้าน การรันโปรแกรม, envoriment, ข้อมูลถูกประมวณผลยังไง)

Abstract Program Model

• โปรแกรมจะต้องอ่าน Input มาจากหลากหลายช่องทาง ประมวณผลข้อมูล และส่งข้อมูล Output ออกไปในหลากหลางช่องทาง
• จะต้องคำนึงถึง และ ตรวจสอบให้ครบทุกช่องทาง

Handling Program Input

• Input อาจจะมาจาก คีย์บอร์ด, file, network, execution enviroment, config data
• มี 2 ส่วนหลักๆ ในการตรวจสอบ
  • ขนาดของ Input
  • ความหมายของ Input

Input size & Buffer overflow

• เมื่อข้อมูลที่จะมาเก็บ ใหญ่กว่าขนาดของ Buffer
• Buffer สามารถเป็น Stack, Heap, Global data

• Input จะเขียนข้อมูลทับ Memory ที่มี Executable code อยู่
• การเขียนข้อมูลทับ พื้นที่ Memory ที่ติดกันจะทำให้
  • ข้อมูล Corruption
  • Unexpected transfer of control
  • Memory access violation
  • Execution of code chosen by attacker

Buffer Overflow attacks

1. ค้นหาช่องโหว่ Buffer Overflow ในโปรแกรม
   • ดู Source code
   • Tracing the execution
   • ทำการ Fuzzing (กรอกข้อมูลมั่วๆ)
2. ตรวจสอบว่า Buffer ถูกเก็บยังไงในหน่วยความจำ และโอกาสในการ Corruption
   • Corrupt พื้นที่ Memory ที่ติดกัน
   • เปลี่ยนการทำงานของโปรแกรม

Stack Buffer Overflow

• เกิดขึ้นเมื่อมีการ Copy ข้อมูล แต่ข้อมูลนั้นใหญ่กว่า Buffer ที่อยู่บน Stacks

• การแทรก Shellcode (โค้ดที่ประสงร้าย) ไปในส่วนของ Buffer ที่ Overflow และเขียนทับ Return address เดิม ก็จะทำให้สามารถเรียก Code อะไรก็ได้
• การโจมตี Stack overflow แบบอื่นๆ
  • System utility
  • Network service deamon (โปรแกรมที่รันใน Background)
  • Library code

การป้องกัน Buffer Overflow

ป้องกันใน Compile-time

• พัฒนาโปรแกรมโดยใช้ภาษาใหม่ๆ ที่เป็น High-level languages ที่ีมี Strong notion of variable type (มี type)
• ถ้าหากจะใช้ภาษาที่ไม่ปลอดภัยอย่าง C ก็ควรเขียนให้ปลอดภัยที่สุด
  • gets(char *str), sprintf(char *str, char *format, ...), strcat(char *dest, char *src), …

ป้องกันใน Run-time

• Stack protection
  • ตรวจสอบ Stack ว่ามีการ Corruption ไหม หากมีให้หยุดรันโปรแกรม
  • ใช้ Random canary (ค่าปลอมระหว่าง Address ของ Memory หากมีการใช้งานแสดงว่าเกิด Buffer Overflow)
    • Stackguard
  • ตรวจสอบ และ เก็บ Return address ที่ถูกต้อง
    • Stackshield, RAD (Return Address Defender)
• Non Executable Address Space: ให้พื้นที่บางส่วนของ Memory ไม่สามารถรันโค้ดได้
• Address Space Randomization: สลับตำแหน่งของ Stack, Heap, Global data
• Guard Pages: วาง Guard pages ไว้ระหว่างส่วนที่สำคัญใน Memory
  • แจ้ง MMU ไว้ว่าพื้นที่ตรงนี้เป็น Illegal address (พื้นที่ที่ไม่ควรเข้า)
  • หากมีการเข้าให้หยุดการทำงาน

Interpretation of Input

• Input ของโปรแกรมสามารถเป็นได้ทั้งตัวอักษร และ Binary
  • ตัวอักษรจะเก็บใน Character set (เช่น ASCII)
  • ถ้าเก็บในอยู่แบบของ Binary ก็จะขึ้นอยู่กับการ Encoding และการนำไปใช้งาน
  • ซึ่งจำเป็นจะต้อง Validate ก่อนที่จะใช้งาน
    • Filename, URL, Email address, identifier

Injection Attacks

• ช่องโหว่ที่จะทำให้ Input ที่ผิดปกติ สามารถมีผลการทำงานของโปรแกรม

• สามารถรับมือด้วยการ Validate input

• SQL Injection

  • ; — + ’ () = > < @

  $name = $_REQUEST['name'];
  $query = "SELECT * FROM suppliers WHERE name = '" . $name . "';";
  $result = mysql_query($query);

  หากเมื่อ users กรอกชื่อเป็น Bob' drop table suppliers ก็จะได้ SQL Query เป็นแบบนี้

  SELECT * FROM suppliers WHERE name = 'Bob' drop table suppliers --';

  • การป้องกัน
    • หลีกเลี่ยงการออกแบบ Application ที่มีช่องโหว่
    • ป้องกันไม่ให้ ส่วนของ SQL ที่มีการโจมตีถูกรัน
    • Input sanitation

• Code Injection

  • หาก users กรอก $path เป็น urls ที่มีการโจมตีอยู่ ระบบก็จะรันไฟล์นั้นๆ

<?php
include $path . 'functions.php';
include $path . 'data/prefs.php';

Cross Site Scripting Attacks (XSS)

• “Cross-Site” หมายถึงการส่ง scripts ผ่านเซิฟเวอร์ไปยัง client

  • ผู้บุกรุกให้ server ส่งโค้ดที่มีการโจมตีไปเครื่องอื่นๆ
  • Malicious script จะถูกรันใน Browser ของ client

• Cross-Site Scripting จะต้องมี 3 conditions

  1. Web application จะต้องรับ Input จาก usrs
  2. Input จะถูกนำไปสร้าง Dynamic content
  3. Input ไม่ได้ถูก validate มากพอ

• การโจมตี 2 รูปแบบ

  1. Stored: server เก็บ Input ไว้และส่งให้คนอื่นๆ
  2. Reflected: server ไม่ได้เก็บ Input แต่จะส่งต่อไปให้คนอื่นๆ ที่ขอมา
  Type of XSS Attcks

• การรับมือ

  • Input validation
    • White-listing: a-z, A-Z, 0-9, etc.
    • Black-listing: < > ( ) # &
  • Output encoding (htmlEncode output)
  • ตัด Input ให้ไม่ยาวเกินไป

Software and Data Integrity Failures

• ความซับซ้อนของโปรแกรมทำให้ Developer จำเป็นต้องใช้ Plugins, Modules, Library ที่ไม่สามารถเชื่อถือได้
• จากความซับซ้อน, Software and data integrity failures จะเกิดขึ้นเมื่อ Software update ถูกปล่อยใช้งานโดยไม่มีการตรวจสอบความ Integrity
• OWASP Top Ten 2021 ได้กำหนด Software and data integrity failures (A08) ไว้เป็นข้อแปด

• การป้องกัน
  • Digital Signatures
  • ใช้ Library และ Dependencies ที่ปลอดภัย
  • ทำ Code Reviews
  • Implement a Software Supply Chain Security Program

Validating Input Syntax

• เปรียบเทียบกับข้อมูลที่ถูกต้่อง
• มักจะใช้ Regular Expressions
  • Pattern ของ ตัวอักษรที่รับได้
• ถ้าเป็นข้อมูลที่ผิด ก็จะถูกปฏิเสธ

Validating Numeric Input

• ตัวเลขมักจะเป็น Fixed sized value
  • 8, 16, 32, 64-bit integers or 32, 64, 96 float
  • signed หรือ unsigned
• ต้องตีความรูปแบบข้อความอย่างถูกต้อง
• ปัญหาต่างๆ
  • เปรียบเทียบค่า unsigned กับ signed
  • Buffer overflow check

Input Fuzzing

• เคร่ืองมือทดสอบ Input ด้วยการสุ่ม Input
  • เพื่อทดสอบว่าโปรแกรม รองรับข้อมูลที่ผิดปกติ ครบหรือไม่
  • ง่าย
• แต่อาจจะพลาด Input บางอย่าง (อาจจะไม่ได้ Random)

Writing Safe Program Code

• การประมวลผลข้อมูล (Algorithm)
• การ Compile โค้ดเป็น Machine code หรือ การ Interpreted
• ปัญหา
  • Algorithm จะต้องคำนึงทุก ทุกปัญหา
  • Machine code จะต้องถูกต้อง
  • ควบคุมการใช้งานข้อมูล

Safe Temporary Files (ไฟล์ชั่วคราว)

• ชื่อไฟล์ต้อง unique และ คนอื่นต้องเข้าถึงไม่ได้
• อาจจะสร้างมาจาก Process ID
  • unique แต่จะสามารถเดาได้
• Temp file ที่ปลอดภัย ต้องใช้ชื่อที่ Random
• ต้องมี Permissions เข้าถึงไฟล์ที่ถูกต้อง

Good Design Principle

• Least privilege: การทำงาน หรือ ผู้ใช้งาน จะได้สิทธิ์ที่ต่ำที่สุดเสมอ (ที่จะมากพอที่จะทำงานได้)
• Economy of mechanism: ต้อง เล็ก, ง่าย, ตรงตัว
• Open design: การออกแบบระบบ จะต้องเปิดเภยต่อสาธารณะ
• Complete mediation: การเข้าถึงข้อมูลถึงอย่างต้องมีการเข้าถึง
• Permission based: default condition คือทุกคน ต้องไม่มีสิทธิ์
• Separation of privilege: การเข้าถึงข้อมูลต้องมีมากกว่า 1 conditions เช่น user authentication และการ cyptographic key (การทำแบบนี้ หากผู้บุกรุกโจมตี 1 อย่าง ก็จะยังไม่สามารถเข้าถึงได้เลย)
• Least common mechanism: ข้อมูลที่มีการ shared กัน มักจะมีช่องโหว่
• Ease of use: ต้องใช้งานง่าย

Computer Emergency Response Team (CERT) Top 10 Secure coding practices

1. Validate input
2. Heed compiler warnings
3. Architect and design for security policies
4. Keep it simple
5. Default to deny
6. Adhere the priciple of least privilege
7. Sanitize data sent to other systems
8. Practice defense in depth
9. Use effective quality-assurance techniques
10. Adopt a secure coding standard

---