Weakness in depth
Software
• runs on a huge, complicated infrastructure
– HW, OS, platforms, web browser, lots of libraries & APIs, ...
• is built using complicated languages
– programming languages
and input languages (SQL, HTML, XML, …)
• using various tools
– compilers, IDEs, pre-processors, dynamic code downloads
All of these may have security holes, or may make the
introduction of security holes very easy & likely
1
Types of software security problems
2
Weaknesses vs vulnerabilities
1. (potential) security weaknesses (an application error or bug)
Things that could go wrong & could be better
2. (real) security vulnerabilities (Weakness may escalate to a
vulnerability )
Flaws that can actually be exploited by an attacker
Requires flaw to be
accessible: attacker has to be able to get at it
exploitable: attacker has to be able to do some damage with it
Eg: by turning off Wifi and BlueTooth on my laptop, many vulnerabilities
become weaknesses
3
Typical software security flaws
0%
17%
buffer overflow
37%
input validation
code defect
design defect
26%
crypto
20%
SQL Slammer is a 2003 computer worm (exploited a Buffer Overflow vulnerability in MS
SQL Server 2000 database) that caused a DoS on some Internet hosts and dramatically
slowed general Internet traffic and crashing routers all around the world. It spread
rapidly, infecting most of its 75,000 victims within 10 minutes.
4
‘Levels’ at which security flaws can arise
1. Design flaws
introduced before coding
2. Implementation flaws aka bugs aka code-level defects
introduced during coding
As a rule of thumb, coding & design flaws equally common
Vulnerabilities can also arise on other levels
3. Configuration flaws
4. Unforeseen consequences of the intended functionality
5
Types of implemention flaws
2a. Flaws that can be understood by looking at program itself
Eg. typos, < instead of <= ..., mistake in the program logic with
wrongly nested if-statements, ...
2b. Problems in the interaction with the underlying platform
or other systems and services, eg
– memory corruption in C(++) code
– SQL injection in program that uses an SQL database
– XSS, CSRF, SSI, .... in web-applications
– Deserialisation attacks in many programming languages
– ...
6
Bug vs features, yet again
Attacks can not only exploit bugs, but also features
Eg: SQL injection uses a feature of the back-end database
A bug is an unexpected problem with software or hardware. 7
The depressing state of software security
The bad news
people keep making the same mistakes
The good news
people keep making the same mistakes
…… so we can do something about it!
“Every upside has its downside” [Johan Cruijff]
8
Spot the security flaws!
int balance; <= should be >=
what if amount
void decreaseBankBalance(int amount)
Is negative?
{ if (balance <= amount)
{ balance = balance – amount; }
else { println(”Insufficient funds\n”); }
}
void increaseBankBalance(int amount)
{ balance = balance + amount;
}
what if this sum is too
large for an int?
9
Different kinds of implementation flaws
1. Lack of input validation
what if amount
is negative? Maybe this is a design flaw? We could
decide not use signed integers.
Root cause: implicit a s s u m p t i o n
<= should be >= 2. Logic error
3. Problem in interaction with underlying
what if sum is too
platform
large for a 32 bit int?
‘Lower level’ than the flaws above
Root cause: b r o k e n a b s t r a c t i o n
10
How can we make software secure?
We do not know how to do this!
Even if we formally verify software, we may
• miss security properties that need to be verified
• make implicit assumptions
• overlook attack vectors
• …
11
How can we make software more secure?
We do know how to do this!
• Knowledge about standard mistakes is crucial
– These depends on programming language, “platform”,
APIs/technologies used, type of application
– There is LOTS of information available on this nowadays
• But this is not enough: security to be taken into account
from the start, throughout the software development life
cycle
– Several ideas, best practices, methodologies to do this
12
Security in the
Software Development Life Cycle
(SDLC)
13
Security in Software Development Lifecycle
Security-by-Design
Privacy-by-Design
Evolution of Security Measures
Threat Training Bug bounty
Modelling Risk Coding program
Analysis guidelines Patch
Management
Security System
Requirements Patch
Abuse Static Security Pen Security
Cases Analysis tests testing incidents
Requirements Design Coding Testing Deployment
and use cases
………………………>………………….…… Do nothing ……………………>………………………………..
pen test: is an authorized simulated attack 14
abuse cases describe how users misuse or exploit the weaknesses
“Shifting left”
Organisations always begin tackling security at the end of
the SDLC, and then slowly evolve to tackle it earlier
1. First, do nothing
2. Some security issue is discovered:
a) Still do nothing, if there’s no (economic) incentive
b) Or: patch
3. If this happens often: update mechanism for regular patching
4. Do security testing: eg. hire pen-testers or bug bounty program
5. Use static analysis tools when coding
6. Give security training to programmers
7. Think of abuse cases, and develop security tests for them
8. Think about security before you start coding, eg with
security architecture review
9. ...
Traditional Security Implementation method is inefficient
DAST, SAST, ….
Security people keep inventing 4 letter new acronyms
• DAST
– Dynamic Application Security Testing
– ie. testing
• SAST
– Static Application Security Testing
– ie. static analysis
• IAST
– Interactive Application Security Testing
– manual pen-testing
• RASP
– Run-time Application Security Protection
– ie. monitoring
16
Methodologies for secure software development
• Microsoft SDL
with extension for Secure DevOps (DevSecOps)
• BSIMM (Building Security In Maturity Model)
• Open SAMM (Software Assurance Maturity Model)
• Gary McGraw’s Touchpoints
• OWASP SAMM (Open Worldwide Application Sec. Proj.)
• Grip on SSD (Secure Software Development)
Ongoing initiative by Dutch government organisations
https://www.cip-overheid.nl/en/category/products/secure-software/
• …
These come with best practices, checklists, methods for
assessments, roadmaps for improvement, …
17
Microsoft’s SDL Optimisation Model
18
Security in the software development life cycle
McGraw’s Touchpoints
[Source: Gary McGraw, Software security , Security & Privacy Magazine,
IEEE, Vol 2, No. 2, pp. 80-83, 2004. ]
19
OpenSAMM
With 4 business functions and 12 security practices
20
BSIMM (Building Security In Maturity Model)
Framework to compare your software security efforts with
other organisations
Based on data collected from large enterprises
https://www.bsimm.com/framework/
21
BSIMM: comparing your security maturity
22
But first…
23
Crucial first step in any security discussion!
1. What are your security requirements?
What does it mean for the system to be secure?
2. What is your attacker model?
Against what does the system have to be secure?
– Attack surface / attack vectors
– Attacker ’s motivations & capabilities
– What are your security assumptions ?
Any discussion of security without answering these
questions is meaningless
Aka threat modelling
24
Security requirements
a) ‘This application cannot be hacked’
• generic default requirement ☺
• vague & not actionable
• negative security model
b) More specific security requirements
• In terms of Confidentiality, Integrity and Availability (CIA)
• Or, usually better, in terms of Access Control
(i.e. Authentication & Authorisation)
• Not just Prevention but also Detection & Reaction/Response
• positive security model
25
prevention vs detection & reaction
26
prevention vs detection & reaction
• Prevention seems to be the way to ensure security, but
detection & response often more important and effective
– Eg. breaking into a house with large windows is trivial;
despite this absence of prevention, detection & reaction still
provides security against burglars
– Most effective security requirement for most persons and
organisations: make good back-ups, so that you can recover
after an attack
• don't ever be tempted into thinking that good
prevention makes detection & reaction superfluous.
• Hence important security requirements include
– being able to do monitoring
– having logs for auditing and forensics
– having someone actually inspecting the logs
– ...
27
Pen Test
Penetration Testing
Definition
- A penetration test or pentest is a test evaluating the
strengths of all security controls on the computer
system. Penetration tests evaluate procedural and
operational controls as well as technological
controls.
Who needs Penetration Testing
- Banks/Financial Institutions, Government Organizations, Online
Vendors, or any organization processing and storing private information
- Most certifications require or recommend that penetration tests be
performed on a regular basis to ensure the security of the system.
- PCI Data Security Standard’s (Cardholder’s data) requires organizations
to perform application and penetration tests at least once a year.
- HIPAA Security Rule's section 8 of the Administrative Safeguards
requires security process audits, periodic vulnerability analysis and
penetration testing.
Penetration Testing Viewpoints
- External vs. Internal
Penetration Testing can be performed from the viewpoint of an
external attacker or a malicious employee.
- Overt vs. Covert
Penetration Testing can be performed with (Overt) or without
(Covert) the knowledge of the IT department of the company being
tested.
Phases of Penetration Testing
1. Reconnaissance and Information Gathering
2. Network Enumeration and Scanning
3. Vulnerability Testing and Exploitation
4. Reporting
1. Reconnaissance and Information Gathering
Purpose: To discover as much information about a target
(individual or organization) as possible without actually making
network contact with said target.
Methods:
• Google search
• Website browsing
• Organization info discovery via WHOIS
WHOIS Results for www.clemson.edu
https://whois.domaintools.com/
Domain Name: CLEMSON.EDU
Registrant:
Clemson University
340 Computer Ct
Anderson, SC 29625
UNITED STATES
Administrative Contact:
Network Operations Center
Clemson University
340 Computer Court
Anderson, SC 29625
UNITED STATES
(864) 656-4634
[email protected]
Technical Contact:
Mike S. Marshall
DNS Admin
Clemson University
Clemson University
340 Computer Court
Anderson, SC 29625
UNITED STATES
(864) 247-5381
[email protected]
Name Servers:
EXTNS1.CLEMSON.EDU 130.127.255.252
EXTNS2.CLEMSON.EDU 130.127.255.253
EXTNS3.CLEMSON.EDU 192.42.3.5
2. Network Enumeration and Scanning
Purpose: To discover existing networks owned by a target as well
as live hosts and services running on those hosts.
Methods:
• Scanning programs that identify live hosts, open ports, services,
and other info (Nmap, autoscan)
• DNS Querying
• Route analysis (traceroute)
• https://nmap.online/
NMap Results
Nmap is used to discover hosts and services on a computer
network by sending packets and analyzing the responses.
nmap -sS 127.0.0.1
1
2
3 Starting Nmap 4.01 at 2006-07-06 17:23 BST
4 Interesting ports on chaos (127.0.0.1):
5 (The 1668 ports scanned but not shown below are in state: closed)
6 PORT STATE SERVICE
7 21/tcp open ftp
8 22/tcp open ssh
9 631/tcp open ipp
10 6000/tcp open X11
11
12 Nmap finished: 1 IP address (1 host up) scanned in 0.207
13 seconds
State
Open port – there is a service listening from
this port and is not blocked by the firewall.
Closed – there is no service listening for
connection on that port.
Filtered – something (firewall, network issue,
or filter) blocking connection to that port
3. Vulnerability Testing and Exploitation
Purpose: To check hosts for known vulnerabilities and to see if
they are exploitable, as well as to assess the potential severity of
said vulnerabilities.
Methods:
• Remote vulnerability scanning (Nessus, OpenVAS)
• Active exploitation testing
o Login checking and bruteforcing
o Vulnerability exploitation (Metasploit, Core Impact)
o 0day and exploit discovery (Fuzzing, program analysis)
o Post exploitation techniques to assess severity (permission
levels, backdoors, rootkits, etc)
o https://hostedscan.com/openvas-vulnerability-scan
4. Reporting
Purpose: To organize and document information found during
the reconnaissance, network scanning, and vulnerability testing
phases of a pentest.
Methods:
• Documentation tools (Dradis)
• - Framework helps you manage information security projects.
o - Organizes information by hosts, services, identified hazards
and risks, recommendations to fix problems
Website Scanner- PentesterTools
https://pentest-tools.com/website-
vulnerability-scanning/website-scanner
View Reports
How to Become a Penetration Tester
- Stay up to date on recent developments in computer security,
reading newsletters and security reports are a good way to do
this.
- Becoming proficient with C/C++ and a scripting language such
as PEARL or Java Script
- Microsoft, Cisco, and Novell certifications
- Penetration Testing Certifications
- Certified Ethical Hacker (CEH)
- GIAC Certified Penetration Tester (GPEN)
Network Enumeration and Scanning
Purpose: To discover existing networks owned by a target as well
as live hosts and serviceENDs running on those hosts.
Methods:
• Scanning programs that identify live hosts, open ports, services,
and other info (Nmap, autoscan)
• DNS Querying
• Route analysis (traceroute)
