Software security

1

Corporate Information Security

Software Security

Jarno Niemelä Jargon@iki.fi

2

Software Vulnerabilities
●

Memory corruption attacks
–

–

Signed and Unsigned values

–

●

Buffer Overflows
Format string vulnerabilities

Command injection attacks
–

–

Cross site scripting

–

●

SQL injections
Path escalations

Access privilege attacks
–

SQL/HTTPD user able to create files

–

Applications having access outside of their own data domain


3

Buffer Overflows
●

●

●

Buffer overflow is caused when program writes more data to
buffer than is allocated for it
This extra data can write over the function stack and return
address
Which means that instead of returning normally from
function, attacker can direct the program to his own code

●

This is called arbitrary code execution

●

Simple example

●

char buf[200];
gets(buf);


4

Unsigned To Signed Conversion Error
●

●

Good code should always check all incoming data for
correct size, but also that can be done badly
char buffer[200];
int dataSize;
if(dataSize<200)
memcpy(buffer,data,dataSize);

●

memcpy is expecting unsigned int and we are giving signed

●

Which means that value will be converted unsiged int

●
●

-1 in unsigned is 0xFFFFFFFF - 1= 4294967294
So in other words the check gives no protection


Are Memory Corruption Attacks Really
That Simple
●
●

●

●

●

Yes, if we are talking about ancient code
Modern OS memory management and compilers make
exploiting memory corruption more difficult
However with time and skill attackers still can take
advantage of memory corruption
This means that you have one smart guy discovering a
vulnerability and creating exploit
And then horde of less talented attackers using it


5

6

SQL injections
●

●

SQL injection means attacker adding his own SQL
commands over user input
For example typical password check uses command
–

–

What if you enter foo' or 1=1?

–

Select user from users where password='foo' or 1=1

–

●

Select user from users where password='%s'

Or “..where password='foo'; delete * from users;

The problem is that unless programmer sanitizes all input
attacker can close statement and continue with another SQL
statament within same string


7

What Can Be Done With SQL Injections?
●
●

Bypass password checks
Alter operation, for example order password reset for any
user to any email

●

Modify database contents, for example prices in web shop

●

Write files to system, execute files

●

Basically anything that the SQL user is capable of


8

Format String Vulnerabilities
●

String formatting is very powerful coding tool
–

●

Something simple as “ERROR file %s” not found can be bad
–

–

●

But it can be like juggling with chainsaws
If attacker can manipulate the file name he can include more
format string options
Which can result in buffer overflow or memory writes

Also consider “select * from users where user=%s;”
–

Can become “select * from users where user=1; delete from
users;”


9

Error Reports
●

●
●

●

●

Probably everyone has seen badly written web pages
that show very verbose error message.
Sometimes even Java/etc stack trace is included
This is a very bad practice as if site has SQL injection
vulnerability the error report page can be used to leak
information
If attacker gets to insert his own SQL, he can print database
contents instead of error reports
Never show error details to user, have just nice clean error
page and log all important information do not show it over
the web.


10

How To Avoid Vulnerabilities
●

●

●

●

There are many ways to detect and prevent programming
errors that lead to vulnerability
However with the amount of code being written it is practical
impossibility to avoid vulnerabilities in large applications
So instead of just trying to avoid errors applications have to
be designed so that single error does not give full access to
everywhere
The principle is the same as with any other security
–

Build security in from the start

–

Modularize your system

–

Prevent, detect, respond, learn, improve


Security Should Start In Architectural
Level
●

●

●
●

●

11

Like in building security the earlier you plan security in the
cheaper it will be in the long run
So while you are planning architecture for your software,
you also need to plan the security architecture for it
Start security by defining software architecture document
The document is needed to gather your thoughts just what
you need to cover in order to create secure software
By thinking about security right from the start you can
minimize the need to modify things to make them secure
later


12

Security In Software Architecture
●

●

Start architectural planning from your business process,
forget all about servers and technology for a moment
Model all your business actions in conceptual level
–

–

●

Imagine system components as people

–

●

Imagine the model as physical office
Who can cheat and how

Think ways how you can prevent your components from
cheating
Think what you need to create yourself and what you can
get ready from others


Things Software Architecture Should
Cover
●

How much security you need

●

Standard engineering techniques you can employ

●

Secure code and libraries you can use, are they secure?

●

Your basic assumptions what you are protecting against

●

Chain of trust between components

●

Communications security between servers, don't be Google

●

Error handling,failure tolerance and graceful degradation

●

Safe default actions and values

●

Multiple layers of defense

●

Make sure someone is accountable for each major part

●

Enemy


13

14

Software Design
●

This is the part where money is either saved or wasted

●

Make sure that your design follows security architecture

●

●

When you design software, you have to make sure that
things are inherently secure
Fixing security problems when software is in production is
60 times more expensive than preventing it at design stage
–

Soo Hoo K, Sudbury AW, & Jaquith AR, Secure Business
Quarterly, 5 pp, Q2 2001


15

Secure Design Steps
●

Access the risks and threats
–

–

How much it costs

–

●

What can go wrong
What legal requirements you have

Adopt a risk mitigation strategy
–

Accept the risk (do nothing)

–

Minimize risk by reducing probability or damage

–

Transfer the risk to insurance or customers (banking, credit
cards)


16

Secure Design Steps
●

Construct mental models
–

●

Systems are hard to think about, so construct analogies

Decide on high level technical issues
–

What language to use

–

How to authenticate users

–

How to audit that your program functions correctly

–

How to defend against attacks


17

Secure Design Steps
●

Select security techniques and technologies
–

–

What code verification tools to use

–

How to test against attacks

–

What third party security libraries and tools are needed

–

●

What development and testing tools to use

How to ensure that tools do their job

Plan operation and maintanance
–

How to monitor system performance

–

How to administer user accounts

–

How to backup and how to recover from total failure


18

Requirements For A Secure Design
●

Each part of business process is isolated from others

●

Each component has access only to data it needs

●

Component that only reads data has no write access

●

Component that only writes data has no read access

●

●

●

Access to data is monitored and unnecessary reads are
forbidden
Components that handle only internal data must not
communicate outside of business process
What component does not need must be blocked


19

Secure Design Example
●

●

You have web shop that needs database for inventory,
pricing and transactions and transactions
Should you place DB on same or different server?

Same server

Different server

●

Cheaper

●

●

Simpler to install

●

●

Simpler to administrate

●

Can be made secure

●

But if security fails,all
data is available to
attacker


●

●

More expensive
Web shop can be
isolated from database
Attack on web fronted
does not give full access
to database
Easier to detect
unauthorized access

20

Results of Proper and Improper Design
Both Kaspersky and F-Secure had SQL injections
Kaspersky
●

●

●

●

SQL injection in
support form
Leaked confidential
data
User names, activation
codes, lists of bugs,
admins, web show
tables
178 news articles


F-Secure
●

●
●

●

SQL injection in
statistics server
Isolated database
DB contained only
public data that was
accessible from our
statistics page anyway
41 news articles

21

Security In Software Implementation
●

Inform yourself
–

●

Handle data with caution
–

●

Allow other components to fail so that you can recover

Create extensive unit tests
–

●

Don't trust anything that comes outside of your system

Don't trust other components
–

●

Know how code is attacked so you can defend it

Always test with bad data and attack code

Create culture of code review and get tools for it
–

Make sure that all code is inspected by another developer


22

Inform Yourself
●

You need to know all about attacks that apply to your code

●

Fortunately there are a lot of information resources available
–

–

http://java.sun.com/javase/technologies/security/index.jsp

–

http://msdn.microsoft.com/en-us/security

–

●

http://www.owasp.org/

http://www.addedbytes.com/php/writing-secure-php/

Identify what languages and resources you are using and
google around before starting to code


23

Handle Data With Caution
●

Basically all exploits are based on feeding bad data
–

●

So handle data like a basket of snakes

Always sanitize or parametrize all data
–

–

For example in user names turn O'hara to O'hara

–

●

You need to know what is acceptable data, and filter it
Or use libraries that do proper escaping for you

Don't trust anything you read
–

–

If you are reading something that has length information, don't
trust it. Have safe maximum length
Don't wait forever for data that does not arrive, always have
timeout


24

Use System Access Controls
●

Divide different parts of your application under different
users, both system users and SQL users
–

●

Code that does not write, must have read only access.
–

●

For example JSP code that displays shop inventory

Code that only writes does not need read access
–

●

Divide by function, web UI, support forms, transaction
processor all need own users.

Support form that stores user feedback does not need to be
able to read what it has written

If possible place each component to it's own container
–

And have monitoring script for extra files


25

Use Secure Coding Methods
●

Know what functions are dangerous in your language
–

Find out what is safe alternative

●

For example in C you have strcpy and strncpy

●

Avoid building dynamic SQL
–

–

●

Use parametrized queries so that input cannot modify
statement
In other words, use prepared statements or SQL functions

Read secure coding resources for whatever language you
are working on


26

Store Passwords Safely
●

Never store them in cleartext, calculate hash and store that

●

Don't use plain hash, they can be cracked in seconds

●

Use salt to prevent rainbow tables (precalculation attacks)
–

–

–

●

Salt recipe: static random data+username+password
This way attacker has to know your salt value before he can
try dictionary or brute force attack on passwords
However if attacker has system level access, he has your
code and thus knows how your salt is formed

What you want to use is something that is VERY slow to
calculate, so bruteforcing will be >10000 slower than with
simple SHA-1 or SHA-256 hash


27

Basic Version Of Slow Hash
import hashlib

●

hasher=hashlib.sha256()
hashed_pw="password"
salt="457897696840"

●

user="joefoo"
hasher.update(hashed_pw+user+salt)
●

for i in xrange(124220):
hasher.update(hasher.hexdigest()+user+salt)
print hasher.hexdigest()

●

●

●


What we are doing here is feeding
the password and two salts through
SHA-256 hashing loop
As each iteration of SHA-256 gets
input from previous none of the
iterations can be skipped
Thus attacker has to spend 124220
times longer than with simple
SHA-256
Procedure is known as key
strengthening or streching
The example code runs in about 0.5
seconds in my old desktop
However it is not advisable to write
your own implementation. Go with
reviewed example code

28

Well Known Slow Hash Implementations
●

RSA PKCS #5: Password-Based Cryptography Standard
–

–

●

PBKDF2 is well known hashing scheme that uses SHA-1 or
other hash algorithm with multiple iterations
Http://en.wikipedia.org/wiki/PBKDF2

Bcrypt, other well known slow password implementation
–

–

●

Java: http://www.mindrot.org/projects/jBCrypt/
Python: http://www.mindrot.org/projects/py-bcrypt/

Scrypt, is designed to make GPU based attacks unfeasible
–

http://www.tarsnap.com/scrypt.html


29

Have Separate Server For Passwords
●

Password DB must not be in UI server

●

Set up separate server with RESTful or other interface

●

Only allowed messages are password query and response

●

Thus frontend server compromise does not compromise DB

●

Alternatively you can use OAuth and outsource
authentication to Google, Facebook or other player
–

Provided that it suits your business model

●

https://developers.google.com/accounts/docs/OAuth2

●

http://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_services


30

Certificate Theft
●

Software world is moving to application stores

●

Which means attacker need certificates to make malware

●

And even without stores certificate helps to hide

●

This means that attackers are very interested in stealing
code signing certificates or any other dev account ID

●

We see code signed malware on daily basis

●

And stolen certificates on almost every week

●

http://www.ccssforum.org/malware-certificates.php?
keywords=&sort_by=id


31

Protect Your Signing Certificate
●

Getting your certificate stolen is really bad PR

●

Thus you need make sure your cert is not stolen

●

At minimum code signing should be done on isolated server

●

Better would be to use hardware security module for signing

●

●

●

●

But even with HSM attacker can still make your code signing
server to sign malware
Thus you have to make sure that human always inspects
what is being signed, or you have content monitoring
http://blog.mozilla.org/security/2013/02/13/using-cryptostick-as-an-hsm/
http://www.thales-esecurity.com/products-and-services/products-andservices/hardware-security-modules


32

Protect Your SSL Certs
●

Just like code signing certs SSL certs are a hot commodity

●

However you must have them on your webserver

●

Which is a bit of a dilemma

●

●

●

You can store it by storing your SSL cert in HSM
or use load balancer that does SSL acceleration
http://www.thales-esecurity.com/products-and-services/products-and-services/hardware-security-modules/general-purpose-hsms/nshield-connect
http://www.kemptechnologies.com/emea/loadbalancingresource/kemp-load-balancer-white-papers-web-ip-load-balancer-information/sslacceleration.html

●

Of course enterprise level HSM are rather expensive

●

Commonly used alternative is to use passphrase a for key

●

And secondary server that gives passphrase on request

●

But this is not nearly as good as real security


33

Use Static Code Analyzers
●

There are a lot of automatic tools that find bugs for yor

●

For example Klocworks
–

http://klocworks.com/

–

Tool that will analyze your code and tell how bad it is

–

●

SQL injection,Process or file injection,ode injection, Cross-site
scripting (XSS), Request forging, etc

But Klockworks is just automated tool, it does not find
everything. Use it to save your time on bugs it does not find


34

Use Vulnerability Scanners
●

●

Like network scanners there are many vulnerability
scanners you can use to find problems in your code
Burb suite is interactive scannert tool that allows to inspect
possible application vulnerabilities
–

–

–

http://www.portswigger.net/burp/
http://www.securityninja.co.uk/hacking/burp-suite-tutorial-theintruder-tool/
Other good tools http://sectools.org/web-scanners.html


35

Fuzzers
●

Exploits are basically broken input to your code

●

Thus you can find vulnerabilities by generating a lot of input

●

This is called fuzzing, it is very effective technique

●

●

●

●

Simply mount your code so that it will receive constant
stream of input from fuzzer, and let it run for couple days
Radamsa is devils own fuzzer
https://code.google.com/p/ouspg/wiki/Radamsa
Given protocol or file sample it is bound to generate input
that will find flaws in code that is not fuzzed before
Fuzz before you get fuzzed


36

Don't Trust Any Network
●
●

●
●

●

●

Only net you can trust is the one where you see cable
Which means that you cannot trust connections between
two of your data centers
Or connections inside cloud hosted provider
Even big players like Google had not encrypted connections
between their own data centers
Which means NSA had really easy time to access all the
data they wanted
Thus all connections between servers should be protected
by properly implemented encryption


37

Security In Day To Day Operation
●

Just building something to be secure is not enough

●

You need to maintain the system properly

●

●

●

●

Know all third party modules you are using, keep track of the
security news on them
When some component has vulnerability, make sure it is
patched
Keep track on new attack techniques, and test your systems
against them
Before SQL injections were known, almost all servers were
vulnerable


38

Rules For Running Good Operation
●

Rotate hardware often enough
–

●

3 years should be maximum server lifespan

Make sure you keep track of system buildup
–

–

●

Log files can consume amazing amount of space over time
What happens if /var or /tmp fills up?

Create custom watchdogs in the system
–

●

If system does not get constant changes in file system, use
integrity checker and alarm on any new files

Make sure that also other than developers know how to fix
the system.
–

Yes I know midnight phonecalls give nice bonus, but...


39

Application Firewalls
●

Application firewalls are content inspecting firewalls that are
placed between network connection and your application
–

Application firewalls know how the protocol works (HTTP)
and can identify malicious content

–

Filter out SQL infections, Cross site scripting, etc

–

Basically they prevent the attack from ever getting into code

●

http://www.breach.com/

●

http://www.applicure.com/

●

http://www.owasp.org/index.php/Web_Application_Firewall


40

Application Firewalls Are Not Silver Bullet
●

Even as application firewalls can prevent attacks they are
not the final word in security

●

App firewall protects only against attacks it knows about

●

Also the firewall itself may be vulnerable to attack

●

●

So if you think code cannot be trusted, and you cannot
replace it, do use firewall
But also start searching replacement for the bad code


41

References
●

OWASP Application Security Community
–

●

Secure Coding Principles & Practices
–

●

O'Reilly, Mark G Graff & Kenneth R. van Wyk

Format String Vulnerabilities
–

●

http://www.owasp.org/

http://julianor.tripod.com/bc/formatstring-1.2.pdf

Stability Anti-Patterns
–

http://www.infoq.com/presentations/Stability-Antipatterns-Michael-Nygard


Software security

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Software security

Ähnlich wie Software security (20)

Software security