Built-in Security Mindfulness for Software Developers

Built-in Security Mindfulness
for Software Developers
Phu H. Phung
Intelligent Systems Security Lab
Department of Computer Science, University of Dayton
https://isseclab-udayton.github.io/
March 11, 2020

Cyber Security Spends and Trends in Companies
•Spends and Trends: SANS 2020 IT Cybersecurity Spending
Survey
All about
network, i.e., cyber
security
But, most of cyber
attacks are not due
to network issues
1

Applications Continue To Be Companies’ Weakest
Security Link
2
Forrester: The State Of
Application Security, 2019
Top 71% of external
attacks are due to
software vulnerabilities

Common Software Vulnerabilities
4

Software Security versus Network (Cyber) Security
5
Program
Process Data
(Structured Program
Internals)
Input Output
Call-out to
other programs
(also consider
input & output issues)
Software Security
Network Security Network Security

Software Security versus Network Security:
An example
•Assume that you are a Paypal user, and assume that Paypal
is on HTTPS and requires two-factor authentication, i.e.,
after providing username/password, you are required to
confirm the login in another device
Network security is fully guaranteed
•Discussion: is it safe for you to open a link like below while
you are logged in on Paypal?
https://www.paypal.com/eg/cgi-bin/cmd=flow&SESSION=Akl-tATMf1GOP-
tQu3t3x4Vju&…
6

Paypal was vulnerable to CSRF
7

Who should be responsible for the Paypal attack
example?
•The user?
 e.g., using anti-virus software?
•Your organization?
e.g., installing anti-virus software, using a proxy filtering,
firewalls?
•The Internet Provider?
e.g., installing firewalls?
Conventional Security Solutions
such as anti-virus software or
firewall cannot prevent attacks
caused by software
vulnerabilities 8

Conventional Security Mechanisms
•Firewall
•Cryptography
•Access control
•System calls/
privileged mode
Treat programs as black box,
cannot address vuneralbilities inside a program
9

Issues of Conventional Security Mechanisms and
Network Security
•Cannot address important current and future security
needs:
Downloaded, mobile code
Buffer overflow, code injection, data races, and other safety
problems
Web application security
Information flow control, e.g., privacy
10

Software Security
•Vulnerabilities in software that cause cyber attacks that can
not be prevented by conventional security mechanisms
 A vulnerability is a flaw in software mostly caused by software
developers
11
Chart source: Trend Micro and the Organization of American States (OAS)

Another Attack Example: A Buffer-Overflow
12
Enter Your PIN:
Attacker can inject
malicious code from input
to exploit vulnerable
programs

Buffer Overflow Example
• A simple program in C, e.g., myecho.c that just print the input:
• Compiling and execution
$ gcc myecho.c -o myecho
$ myecho OISC20
OISC20
Are there any issues
you can see in this
simple program?
How about?
$ myecho $(perl -e 'print "A"x150')
13

Buffer Overflow Attack Live Demo
14
Demo video: https://youtu.be/RAawLvKa-U0

Buffer-Over Flow Attack Examples
•The most common software vulnerabilities that causes
cyber attacks
•Recent and notable examples:
Wannacry, May 2017
o A Ransomware crippling systems worldwide
WhatsApp, May 2019
o Hackers compromise victims’ phone by a phone call that
automatically executes malicious code
15

Source: https://blog.securitycompass.com/wannacry-and-the-elephant-in-the-room-c9b24cfee2bd
16

Are buffer overflow attacks new?
•Buffer overflow is 40 years old!
18

Why does Buffer-Overflow happen?
•Data is read or written outside the bounds of a buffer
The attacker gets the program to treat the malicious data as
code
•How can this happen?
The developer did not check the data size or use insecure
functions in the program!!!
19

Software Development
•Based on a typical software engineering process
Normally developers
focus on the
functionalities
of the application
20
Image source: www.pinterest.com

Security in Software Development
•Developers mainly focus on the functionalities
Few developers know how to develop secure software
o Programming books/courses do not teach it
Most developers do not think like a hacker
o “How could this be attacked?” – be slightly paranoid
Developers do not learn from others’ security mistakes
o Most vulnerabilities caused by same mistakes over 40+ years
Credit: David A. Wheeler
21

Traditional Penetrate-and-Patch Software
Development Approach
•Once a software vulnerability is discovered (normally by
attackers), the software can be patched, but:
Unpatched systems remain vulnerable
Other vulnerabilities might still remain
New vulnerabilities might be discovered
•Zero-day vulnerability attacks exploit this Penetrate-and-
Patch approach
22

Zero-day vulnerabilities
•Undisclosed computer-software vulnerabilities
Hackers can exploit to adversely affect computer systems
oBefore the vulnerability is fixed and patched
23

Security at the source
•The developers should be responsible for security at the
design and development phase
Secure Development Lifecycle has been proposed
Source: “Improving Security Across the Software Development Lifecycle – Task Force Report”, April 1, 2004.
http://www.cyberpartnership.org/init.html; based on Gary McGraw 2004, IEEE Security and Privacy. Fair use asserted.
Credit: David A. Wheeler 24

Built-in Security Mindfulness for Software
Developers at UDayton-CS
•Understanding of the impact of software vulnerabilities (in
Software/Language-based Security course)
•Develop “Building Security In” Approach (in Secure
Application Development course)
Secure and Sustainability Principles and Practices in Application
Development
Avoid security problems at the design stage
25

Software Security/Language-based Security at
UDayton-CS
•Students will learn the practice of software security
how to identify vulnerabilities in computer systems
o white-hat hacker mindset !!!
how to defense against the possible vulnerabilities
•Students can understand the principles of language-based
security
how to design secure systems and write secure code
26

UDayton-CS hands-on example: SQLi Attacks
•Students will need to hack into a real web server (on a
Cyber Range), e.g.: http://myphoto.blog.com/
By exploring and exploiting its SQL Injection Vulnerabilities
Read the data from the database
Obtain the username/password
and login to the system
27

Detect the SQL Vulnerabilities
• Click on a link, e.g.:http://myphoto.blog.com/cat.php?id=1
 Recall HTTP GET Request, inputs are encoded in the URL
• Let’s try several different inputs to detect potential vulnerabilities:
 http://myphoto.blog.com/cat.php?id=1'
28

Detect the SQL Vulnerabilities - More
 http://myphoto.blog.com/cat.php?id=a
 http://myphoto.blog.com/cat.php?id=2-1
• Guessing?
29
SELECT xxx FROM xxx
WHERE xxx=<input>

Exploitation of SQL Injections
• We guessed the SQL
SELECT xxx FROM xxx WHERE xxx=<input>
• How to inject a SQL query for attacks?
 Use UNION:
SELECT xxx FROM xxx WHERE xxx=value UNION SELECT ???
 UNION must have the same number of columns. How do we
know?
oTrials with errors, e.g.,:
• SELECT xxx FROM xxx WHERE xxx=value UNION SELECT 1
30

Exploitation of SQL Injections - more
• We guessed the SQL
SELECT xxx FROM xxx WHERE xxx=<input>
• Trials with errors, e.g.,:
 SELECT xxx FROM xxx WHERE xxx=value UNION SELECT
1
SELECT xxx FROM xxx WHERE xxx=value
UNION SELECT 1, 2
 ...
• Students first do hands-on to identify the number of
columns
 Carry out further attacks 31

Future Software security hacking environment
• We create a practical and
real environment for students
E.g.,:
https://myphoto.ss-lbs.me
for SQL Injection Attacks
https://myblog.ss-lbs.me
for XSS, SQLi, Session Hijacking
CSRF attacks
32

Discussion: How many columns used in the SQL in
https://myphoto.ss-lbs.me/cat.php?id=1
A. *
B. 1
C. 2
D. 3
E. 4
33

Demo: Retrieving username/password
with SQLi Attacks
Students can login with the stolen
username/password
34

Secure Application Development at UDayton-CS
• How to develop application software with “Building
Security In” Approach
 Secure and Sustainability Principles and Practices in Application
Development
Robust and Defensive Programming Techniques
Avoid security problems at the design stage
o Developers with hacker mindset!!
35

Secure Application Development Example:
A Simple Login System
•Code (from the scratch) to authenticate users with
username/password
Check on real database (MySQL)
•Then think as a hacker!
 Doing self-attacks
 Implementing secure code
The query:
SELECT * FROM users where username='admin' AND
password=password('thepassword');
thepassword
36

Username/password check from Database
37
Discussion: What are the potential security risks in this SQL statement?
A. No input validation
B. Attackers can inject SQL code
C. Attackers can inject JavaScript code
D. A and B
E. A, B, and C
sql=SELECT * FROM users where username=' '
AND password=password(' ')
P4$$w0rd
admin
P4$$w0rd

Self-attack Demo: Mixed SQL and JavaScript
38
admin' #<script>alert(document.cookie)</script>
This is an example of code
injection attacks, mixing
SQL and JavaScript. Will be
covered in detail next steps

Prepared Statements in PHP/MySQL
39
Vulnerable SQL Statement
OWASP Primary Defenses against SQL Injection Attacks:
Option #1: Use of Prepared Statements

Built-in Security Mindfulness for Software
Developers at UDayton-CS: A Reflection
•Stable and increasing enrollment
•Very high positive feedback from students
Yoursecureapplication projectis veryusefulforattending interviews.
Dr.Phung,
Ijust wantedtothankyouandalsoletyouknowhowbeneficial yourclass wasinan
interviewIhadacoupleweeksago.
…
Yourclassbenefited meextremelyandIjustwantedtomakesurethatyouknewand
yousothatyoucantellyourclasses what employersmightaskabout.Iendedup
gettingajoboffer15minutes afterIleft theinterview,theysaidthattheywere
trulyimpressed with myrangeofknowledge.
40

Challenges and Opportunities
•Security courses are not mandatory for CS students
 Future developers still write insecure code !!!
•I welcome and look forward to opportunities
 Integrate security components in programming classes
 Collaborate with other colleges to explore the possibilities to
integrate security components in their curriculum
 Work with industry to propose a long-term solution
41

Thank you!
Phu H. Phung
Intelligent Systems Security Lab
Department of Computer Science, University of Dayton
https://isseclab-udayton.github.io/
March 11, 2020

Built-in Security Mindfulness for Software Developers

More Related Content

What's hot (20)

Similar to Built-in Security Mindfulness for Software Developers (20)

More from Phú Phùng (10)

Recently uploaded (20)

Built-in Security Mindfulness for Software Developers

Editor's Notes