Application Security
2007 Annual Security Training
Kansas State University
Introduction
• Jeremiah Shirk
• InfoSec geek for over a decade
– Firewall design
– Security consulting
– Vulnerability and malware research
• Currently, Application Services
Administrator for the Office of Mediated
Education
Office of Mediated Education
• Our mission
–
The Office of Mediated Education is dedicated to providing innovative and reliable
solutions to meet the academic computing needs of K-State in the areas of teaching
and learning as well as research, technology transfer and outreach.
• Project Highlights
– DCE/EIS, Survey, K-State Online / Axio,
Transaction Hub, Electronic Grade
Submission, KEAS, eProfile & WID
Support tools, ExpanSIS,Online TEVAL,
SGA Elections, several Lecture Series, and
too many more to list.
OME Services
•
•
•
•
•
•
•
Web Hosting and Design
Instructional Design Consultation
Live A/V Webcasting
CD/DVD Duplication
A/V Encoding and Editing
Web Presentations
More information available at:
http://ome.ksu.edu/about/
Application Security
• Difficult to define, but the following
comes close
• “everything involved in developing,
maintaining, and purchasing
applications that your organization can
trust”
– OWASP
Why does it matter?
• Attacks focus on data
• Applications have a trusted place in our
networks
• Attacks on applications come in through
avenues that cannot simply be blocked
at the perimeter
Different perspectives
• Commercial applications
– Expect vendor to keep application secure
– Administrators (and users!) have a responsibility
as well
• Home-grown applications
– We are the vendor and user
• Open source application
– Some mix of the above
• All applications
– Ultimately, we are responsible for the security of
all the apps that we install and/or use
Sample attacks
• To illustrate, a few sample attacks
– WinAMP playlist parsing overflow
http://secunia.com/advisories/18649/
– Word memory corruption (CVE-2007-3899)
http://www.microsoft.com/technet/security/Bulletin/MS07-060.mspx
– PHP Project Management file inclusion
http://secunia.com/advisories/27347/
– iPhone TIFF file processing vulnerability
http://secunia.com/advisories/27213/
Scope of the problem
• Vulnerability statistics
– CVE (Common Vulnerabilities and
Exposures) is a widely accepted standard
naming system for publicly known
vulnerabilities
Year 2003
Vulns 1493
2004
2442
2005
4926
2006
6602
* 2007 through mid-October
2007*
5708
Which apps are vulnerable?
• Probably most of them
• Many vulnerabilities are as yet unknown
• In my personal experience:
– Many who have looked for vulnerabilities have
found them
– None who looked at an app reported finding
nothing
– This is admittedly unscientific, but strongly
suggestive
• If you look for vulnerabilities, you will find
them
New threats
• How are new application vulnerabilities
found?
– Input fuzzing
– Patch analysis
• Source, if available
• Binary patch differential analysis
– Executable “debugging”
• Where do vulnerabilities come from?
Developers, but more on that later
Input Fuzzing
• Testing by providing random input to a
program, and noting failures and
exceptions
– Practical fuzzing takes into account data
structures in protocols and/or file formats
– SPIKE, and SPIKE Proxy, PROTOS
– Inputs can include network connections,
files, environment variables, yielding
different attack vectors
Patch Analysis
• When a patch comes out, examine what
changes
• This drastically narrows the scope of
searching for vulnerabilities, which will
work on all un-patched systems
• Tools to make it easier
– Sabre BinDiff
Debugging/disassembling
• Complementary to fuzzing and patch
analysis
– Once you know where the code breaks,
debugging/disassembling lets you find out
how it breaks, and how to exploit it
– Tools
• SoftICE
• IDAPro
• OllyDbg -- Free and powerful
Defense: What can we do?
• Depends on the type of software
– Third party applications
• Open source
• Commercial
– Internally developed applications
• Some strategies for each type
Third-party application
security strategies
• Keep up with patches
• Read the (fine) manual
• Subscribe to security and
announcement mailing lists
• Minimal software footprint
• Select applications with a better security
track record
Keep up with patches
• Pay special attention to security patches, if
the vendor makes the distinction
• Some vendors, such as Microsoft, allow for
automatic patching. For most users, the risk
of a bad patch is less than the risk of a
delayed patch.
• Worms often spread near patch releases
(immediately before and after) so time is of
the essence.
Read the manual
• If your software manual specifically
refers to security, it’s probably important
– Most often true of servers and frameworks
• The PHP manual has multiple chapters on
security
(http://php.net/manual/en/security.php)
• Apache security tips
(http://httpd.apache.org/docs/2.0/misc/security_
tips.html)
Subscribe to security mailing
lists
• Almost all vendors now have a mailing list for
security issues. This is one of the best ways
to know as soon as possible about threats to
your applications
• Details often found at
http://<vendor_web_site>/security
• Or search with Google…these lists almost
always exist
Minimal software footprint
• Avoid installing components you don’t
need
• For servers and frameworks, turn off or
restrict features you won’t use
• The less software you run, the less
chance you are running insecure code
Select secure software
• Some vendors have a better security
track record
• Review security mailing lists: Does the
vendor:
– release patches before vulnerabilities are
disclosed?
– Release patches quickly?
– Give direct information about risks?
Home grown applications
• Security advantages
– Fewer interested attackers
– Security through obscurity
• Security disadvantages
– Responsible for own patches
– Those who find flaws may be less likely to
reveal them
Principles for secure apps
• Input validation
– Defending against fuzzing and ‘smart’
attacks
•
•
•
•
Start with a secure platform
Limit public interfaces
Layered security
Avoid clear-text protocols
Guidelines for secure coding
• Depends on your tool set, but there is a lot of
good help out there
– .Net Security
http://msdn2.microsoft.com/en-us/library/aa286519.aspx
– Secure Coding Guidelines for the Java
Programming Language
http://java.sun.com/security/seccodeguide.html
– Secure Coding in C and C++ (Book)
http://www.cert.org/books/secure-coding/
– CERT Secure Coding Standards (Wiki)
https://www.securecoding.cert.org/
Resources and References
• Open Web Application Security Project
http://www.owasp.org/
• SPIKE, SPIKE Proxy
http://www.immunitysec.com/resourcesfreesoftware.shtml
• PROTOS
http://www.ee.oulu.fi/research/ouspg/protos/
• CERT Secure Coding Standards (Wiki)
https://www.securecoding.cert.org/
• CERT
http://www.cert.org/