Security
CSCI 3308
Spring 2015
A BRIEF INTRODUCTION
Security is about...
people (users, employees, sys-admins, programmers,...),
incompetence, confusion, lethargy, stupidity, mistakes,
access control, passwords, biometrics, cryptology, protocols,
policies & their enforcement, monitoring, auditing, script kiddies,
legislation, persecution, liability, risk management,
complexity, software, bugs, verification, hackers, viruses,
hardware, operating systems, networks, databases,
public relations, public perception, conventions, standards,
physical protection, data protection...
4
Security is about...
people (users, employees, sys-admins, programmers...)
incompetence confusion lethargy
mistakes stupidity
access control passwords biometrics cryptology protocols
policies & their enforcement monitoring auditing script kiddies
legislation persecution liability risks risk management
complexity software bugs verification hackers
viruses hardware operating systems networks databases
public relations public perception conventions standards
physical protection data
protection...
5
Cyber-crime, insecurity, and the media

Dangers of the interwebs
They might be out to get you :o
– Everything is information
– Personal loss/damage
» “doxxing” and identity theft
» Hardware failure
– Gov't and corporate loss
» Embezzlement, fraud
» Vandalism and DDoS
» Espionage and warfare

Fear-mongering?
People keep making the same mistakes



Bad and good news
Errors in writing/designing programs, programming
languages, infrastructure
Ex. a flaw in something you saw earlier: SQL injection!
– video: how this works
– String concatenation is a convenient way to build SQL queries...
SELECT * FROM Users WHERE UserId = 105 or 1=1
– Insist on special character esaping and PreparedStatement?
7
Btw...
“Hacking might be characterized as an appropriate
application of ingenuity. Whether the result is a
quick and dirty patchwork job or a carefully
crafted work of art … cleverness went into it.”
Eric Raymond
!=
Recent vulns










Heartbleed (OpenSSL)
Shellshock (group of Bash bugs)
Poodle (Padding Oracle on Downgraded Legacy
Encryption, attack against TLS)
Adobe Flash (well, not a bug in itself...)
Home Depot, Chik-Fil-A, Morgan Stanley,etc:
credit card information stolen
Ability to hide attack code on USBs/Mac batteries/etc
Sony data breach (the Interview)
“Equation Group” malware discovered
Lenovo and Superfish
FREAK export-strength (weak) crypto attack
(In)security: who?

Black hats, crackers, script kiddies
– Against the law! Cybercrime for highest bidder, vandalism

Grey hat and white hat hacking (mostly legal, sometimes
black hat methods- why?)
– Penetration testing (with permission from system owner)
– Bug bounties and hacking competitions
– 0-days, disclosed responsibly... more on this later
– Security researchers/students, conferences, toolmakers
» Better defenses and crypto
» Break things to understand how to make them better
» Build tools to help people with security and privacy
» FireEye, Matasano, AppliedTrust, Logrhythm, Splunk,
Kaspersky...
– Also, most companies have Information Security Engineers
10
Security: an old, persistent problem

Hardware backdoors

Phishing and social engineering

Applications (web and device-native)

Programming languages

Operating systems

Databases

Anti-virus software (!)

Network and “cloud-based” distributed services

Any other examples?
Everything is vulnerable



Partial answer:
security cannot be a bolt-on afterthought
Most easily exploitable bugs today in
public-facing, networked devices and apps
How does this apply to 3308 and your projects?
MORE VULNERABILITIES
AND ATTACKS
First, basic terminology







Vulnerability: exploitable flaw/weakness
Malware: software created with malicious intent and/or
installed without user knowing/against user's wishes
Attack vector: single method of attack
Attack surface: totality of attack vectors in a system
Payload: malicious software “piggybacking” in
Buffer overflow: program writing data to a buffer “overflows”
allocated memory, overwrites adjacent memory
...
Zero-day exploit
Definition: targets a previously unknown vulnerability that
developers have had “zero days” to fix / address
More: zerodayinitiative.com/advisories/
Virus
Definition: Inserts a copy of itself into another program on an infected
host (attaches to other code)
– Requires user intervention or other help to propagate.

Example attack vectors
–
–
–
–

Executable files
Boot sectors
Macros (spreadsheets and documents)
Scripts and iframes (web pages)
Propagation
–
–
–
–
Plugging in a USB (NB: even in air-gapped networks)
Clicking on e-mail attachments or links
Downloading (and/or torrenting) files
Sharing folders with others
Worm
Definition: Piece of code that automatically reproduces itself over
the network, often crashing hardware/carrying viruses as payload
– Doesn’t need help to propagate (relatively autonomous)

Attack vectors
– Buffer overflow
– File sharing
– Configuration errors

Target selection algorithm
– Email address, DNS, IP, ISP, network neighborhood

Payload (sometimes)
–
–
–
–
–
Virus(es)++
Backdoor
Bootstrap for bot code
Spyware, adware
Other examples?
Bots and botnets
Definition: Automates massive info-gathering, info propagation. Many bots
controlled by one entity (group, person, C&C server) == botnet.
– Sometimes bots only interact with command and control server, e.g. send
back info. May also interact with websites, e.g. DDoS attack

Botnet example attack vectors
– SYN packet flood: router(s) overwhelmed!
– Spam e-mail flood
– NTP (Network Time Protocol) amplification
– User-agent spoofing / fake user-agents
– Store cookies (“I'm a real browser!”)

Bot propagation
– Can be self-propagating (like a worm)
– Bot code can also be worm's payload
Free gifts
Trojans, spyware, adware
– Can be installed via OS, browser, application security holes
– Sometimes even via automatic updates! Be careful what you
install (3rd party software sometimes included)
Spam
– response: spam filters (how complicated do these get?)
– variants: phishing, spear-phishing & whaling (social engineering)
19
Session-jacking and man in the middle
Definition: attacker acquires/copies a valid session key
(cookie) via MITM attack and session hijacks: gets access to
info the actual session holder can access, via stolen key
Session hijacking
Man-in-the-middle (MITM) attack examples
– ARP (Address Resolution Protocol) spoofing
– Attacker tells host/network that attacker's MAC address
resolves to victim's IP
– Attacker can receive all outbound data from host/network
– Replay attacks
– Capture packets to inspect and extract information from later
– Some corporate networks do this to protect the company (check for
spam sending, porn, etc.)
– “Evil Twin” network and session eavesdropping
– Set up rogue router w/ network just like one saved to target's device.
Target's device connects; attacker sniffs/intercepts data
– SSLStrip?
– Partial solutions? As a web site/app engineer...
– Never accept session ids from GET/POST variables
– TLS session identifiers
21
MITM, con't.
- Cross-site scripting (XSS)
- If content from example.com can access system resources, any
content from that site shares that permission
- Other sites should have to ask for their own permission
- Getting around this: attacker injects script into example.com, adds
malicious content to legitimate content that is seen by users
- (XSS-specific) partial solutions:
- disable clientside scripts
- contextually escaping input strings
- Packet sniffing
- Internet traffic is broken into data “packets”, which can be “sniffed”
- Leads to other attacks such as password sniffing, cookie stealing/
session hijacking, information stealing (see previous slide)
BEST PRACTICES
Root causes of insecurity

Security is often a secondary concern
(primary goal: provide some functionality or services
while managing the associated risks)

Trade-off/conflict in usability between
– Security and risk mitigation
– Convenience and functionality
24
Digging deeper

Poorly-written or designed software
–
–
–
–

Bugs/errors in our app (code, API use/abuse)
Bugs in infrastructure/environment
Bugs in security measures
Fix: Patching? Unit tests? Penetration testing?
Users are easily tricked and lack knowledge
– However, too easy to just blame users:
they should be protected, to an extent
– Fix: User edu? K-12 CS classes? Documentation?
Writing and designing good sw from the start?
25
'CIA' Security Model
Microsoft's STRIDE
Simple approach to threat modelling, as part of an SDL
(Secure Development Lifecycle process)






Spoofing Identity
Tampering with Data
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
Erik Poll Digital Security group Radboud University Nijmegen
27
Secure development lifecycle process
[Source: Gary McGraw, Software security, Security & Privacy Magazine,
IEEE, Vol 2, No. 2, pp. 80-83, 2004.]
28
Encryption





Usually not the problem, though can be cracked
– historically increases in computing power
meant encryption redesigns needed (ex. DES)
Sign everything (think firmware exploits)
Use well tested algorithms, libraries
Web encryption: SSL versus TLS?
What is a 'good' password? (hint: shouldn't be in
any dictionary ever compiled)
29
Encryption
"The only system which is truly secure
is one which is switched off and unplugged,
locked in a titanium-lined safe,
buried in a concrete bunker,
and surrounded by nerve gas
and very highly paid
armed guards...
Even then,
I wouldn't stake my life
on it.”
Gene Spafford
30
Encryption and databases
31
Programming language security




Security mainly secondary concern, behind utility
1960: Algol 60 introduces array bounds-checking
1970's: canon C, C++ don't use bounds checking
C, C++, PHP communities still trying to mitigate
buffer overflows and memory corruption errors
Early 2000s: C/++ devs started using safestr.h!
32
How can we improve things?
Include security at all levels of application design and
code, throughout entire SDL.
33
How can we improve things?

At a lower level... proper:
- Data Validation
- Authentication and Password Management
- Authorization and Access Management
- Session Management
- Sensitive Information Storage or Transmission
- System Configuration Management
- General Coding Practices
- Database Security
- File Management
- Memory Management
34
Security/risk/requirements analysis

Take inventory
•
Stakeholders, assets, data
• In your DB/project/app?
• What assets do we have?
• Who is most at risk?
• Potential attackers
• Employees, clients, script kiddies, criminals
• Threats (surface of attack)
• Current flaws and bugs

Understand user needs, balance against threats
35
Countermeasures
Countermeasures can lead to new vulnerabilities.

if we only allow 3 incorrect logins as a countermeasure to brute-force
login attempts, which new vulnerability do we introduce?
If a countermeasure requires software/hardware,
what about bugs/errors?
(Stopgap ineffective? A worse situation?)
36
Threats and mitigation techniques






Spoofing Identity
– authentication, protect keys & passwords
Tampering with Data
– access control, hashes, digital signatures, MACs
(message authentication codes), write-once storage
Repudiation
– logging, audit trails, digital signatures
Information Disclosure
– access control, encryption, not storing secrets
Denial of Service
– graceful degradation, filtering, backup hardware
Elevation of Privilege
– access control (principle of least privilege), sandboxing
37
CONCLUSION
What now?!

Security problems exponentially growing
– more networks, more software, more data, more... everything
– importance of security services increasing as amount of money to
be made by black hats, crackers, and other bad guys goes up



Flaws and bugs will happen
A proper software development lifecycle should
consider security to help mitigate flaws
As a developer, Keep Code Simple
– Fewer, smaller, more well-designed, secure
components with fewer errors ==
smaller attack surface!
39
Prevention: best cure
Understand security requirements,
threats that attackers pose to your system
– Aka threat modeling; think like an attacker
– Have checklist of best practices for developers, follow
it, keep it up to date
know the technologies you use
– operating system
– programming languages, platforms, APIs
– ...
and their security problems
– buffer overflows, SQL injection,
susceptibility to MITM...
40
Interested?

Possibly helpful courses to take in future
– Operating Systems, UNIX System Administration (in TLEN),
Network Systems, Ethical Hacking, Computer Organization,
Machine Learning, Numerical Computation, Compiler
Construction, User-Centered Design




Consider getting certified
– Ethical Hacker (CEH)
– CompTIA Security+
Contribute to open source (seriously)
Hacking club (talk to Andy Sayler)
A couple CTF's and hacking games:
– Overthewire.org, cryptopals.com, hackthissite.org
A few books








The Web Application Hacker's Handbook,
Stuttard
The Art of Software Security Assessment, Dowd
Advanced Programming in the UNIX
Environment, Stevens
Windows Internals, Solomon
Reversing: Secrets of Reverse Engineering,
Eilam
The Practice of Programming, Kernighan
TCP/IP Illustrated (Vols I-III), Stevens
Handbook of Applied Cryptography, Menezes
Tools to try out (ethically...) or git clone











Kali Linux (formerly Backtrack; installed in CSEL)
Metasploit
BeEF: Browser Exploitation Framework
Burp Proxy Suite
Wireshark
Nessus
Zed Attack Proxy (ZAP)
John the Ripper
Nmap
Aircrack-ng
Tor