Date post: | 02-Jan-2016 |
Category: |
Documents |
Upload: | paulina-dennis |
View: | 217 times |
Download: | 1 times |
Fundamentals of Secure Development
Dave WeinsteinSecurity Development Engineer
Microsoft
What is Secure Development?
A process, not a magic bullet or
secret technology
What is Secure Development? Security Development Lifecycle
Secure by Design If you add security as an afterthought, it is just an
afterthought Secure by Default
The default configuration should be secure; normal users should not have to go searching through options to lock things down
Secure in Deployment Provide tools and guidance for securing the
application, and a solid and easy patch and update path
Communications Be prepared for the discovery of vulnerabilities and
communicate openly and responsibly with end users and/or administrators to help them take protective action
SD3+C
What could a major exploited vulnerability mean? If player run servers are vulnerable…
No one will host games If clients searching for games are
vulnerable… No one will play games
If clients in a game with a malicious client are vulnerable… No one will play with strangers
If replays, save games, or mods are vulnerable… The community may die
If your game is vulnerable… The franchise may die
Myths and Misperceptions about Security
Myths and Misperceptions
People writing malicious code are doing it to prove they can People writing malicious code are doing
it primarily for the money. Stolen identities, botnets, stolen credit card information, and so on.
The security research community, on the other hand, has a great many people who investigate security issues because they find it interesting. Conflating the researchers who tell you about security violations with the bad guys who exploit them is another example of misperception.
Myths and Misperceptions
This is an operating system issue, not an application issue. As operating systems become hardened,
the attacks are moving up the application stack. Malware has been found in the wild exploiting instant message clients and audio players. Success in the mass market makes you a target.
Myths and Misperceptions
This isn’t important enough to miss a ship date for “Market seems to act on this information
and punishes a vendor, who on an average, loses around 0.63% of its market value on the day a vulnerability is reported in its products.”
[Telang R and S Wattal (2004)]
The most important thing to realize…
Data is evil(Validated Data is only mostly evil)
Why Data is Evil
Data affects code execution. If you didn’t change software behavior based on the data, you wouldn’t be loading it at all.
Software which naively trusts data from outside sources is easy prey
Without training programmers defend against bugs during development, not against deliberately malformed data in the real world Even with training, simple mistakes can and will
happen
Why Data is Evil
Small errors can have devastating results while (*pwszTemp != L'\\')
*pwszServerName++ = *pwszTemp++;
Blaster involved more than 1.5 million compromised computers, all from a two line coding error.
Why Data is Evil
Data types are not as safe as you think they are Image based vulnerabilities that can
result in remote execution of code have been found on all major operating systems and across the application stack.
Code Vulnerability:Bad APIs
Code Vulnerability: Bad APIs
There are classes of functions which are commonly misused, and are extremely prone to security vulnerabilities. strcpy() strncpy() sprintf() …
Code Vulnerability: Bad APIs Buffer constants are often subject to
change, and the information isn’t necessarily propogated across the code: … fgets( buffer, 256, file ); LogCommand( users[curUser].Name, buffer ); …
void LogCommand( char *user, char *cmd ){
char logString[128];sprintf( logString, “User: %s Command: %s”,
user, cmd );…
}
Code Vulnerability: Bad APIs What about the “n” functions?
// Code verifies pszSrc is <= 50 chars #define MAX (50) char *pszDest = malloc(sizeof(pszSrc)); strncpy(pszDest,pszSrc,MAX);
Human error: sizeof is 4 bytes, not 50
Code Vulnerability: Bad APIs What about the “n” functions?
#define MAX (50)char szDest[MAX];
strncpy(szDest,pszSrc,MAX); Latent error: The string not null-terminated
if len(pszSrc) >= MAX
Code Vulnerability: Bad APIs What about the “n” functions?
#define MAX (50)char szDest[MAX];
strncpy(szDest,pszSrc,strlen(pszSrc)); Human Error: The limiting size is derived
from the source buffer, instead of the destination
Attacks:An Introduction to the STRIDE Taxonomy
STRIDE: Spoofing
What it is: Impersonating a person or machine
What it can gain: Anything that the impersonated entity
can do Countermeasures:
Authentication
STRIDE: Spoofing
Identification Who someone claims to be
Authentication Proof as to their claim of identity
Authorization Proof of their ability to do something
Do not mistake identification for authentication, or authentication for authorization
STRIDE: Spoofing
Example: SSL Certificates An SSL certificate for a web site will
confirm that you are talking to the web site the certificate was issued for.
This means that you were not subject to DNS poisoning, or other means of redirection
It does NOT mean that the web site the certificate was issued for is the web site you SHOULD be talking to. Authentication is not authorization.
STRIDE: Spoofing
Types of authentication Something you are Something you have Something you know
Username / Password Single factor authentication
Smartcard / PIN Two factor authentication
STRIDE: Tampering
What it is: Altering data or data flows
What it can gain: Injection of false or malicious data
Countermeasures: Integrity Checking
Integrity checking and prevention of Information Disclosure are the focus of the Cryptography portion of this presentation
STRIDE: Repudiation
What it is: Denying that an action or transaction took
place What it can gain:
Avoiding the consequences of an action Countermeasures:
“Non-repudiation services generate evidence which will convince a disinterested party that a specific subject performed a specific action”
STRIDE: Repudiation
Repudiation attacks Primarily involve people making claims,
not software issues Can be escalated in some cases to
entities outside the developer or publisher
Credit card companies Legal System
STRIDE: Information Disclosure What it is:
Gaining access to information that should not be available to the attacker
What it can gain: Passwords, account information,
personally identifiable information… Countermeasures:
Confidentiality Encryption
STRIDE: Denial of Service
What it is: Stopping a service or system from running
What it can gain: Revenge for perceived slights The ability to leave a game without “quitting” Blackmail
Countermeasures: Availability Robustness
STRIDE: Elevation of Privilege What it is:
Using one level of privilege to gain a higher level
What it can gain: All the capabilities of the higher level of
privilege Countermeasures:
Authorization
STRIDE: Elevation of Privilege Remote execution of code by an
unauthenticated user is the ultimate Elevation of Privilege. This is the goal of an attacker. UDP sockets that are listening on the
Internet are particularly vulnerable.
STRIDE: Elevation of Privilege Additional Note: Software should run
with the smallest set of privileges possible. There is no reason that a game should require high level privileges to run. The answer to people trying to break
into a building is not to remove the locks. Or the doors.
Code Vulnerability:Format Strings
Code Vulnerability:Format Strings What is wrong with this?
…char buffer[256];
if( strlen( description ) < 256 ){
sprintf( buffer, description );}…
What happens if description consists of “%u%u%u%u%u%...”?
An Introduction to Attack Surfaces and Threat Modeling
Attack Surface
The attack surface of an application is the set of sources of data it accepts. Anything that is providing you with data externally is a potential attack vector.
Game traffic Matchmaking traffic Voice traffic Player provided skins and icons Player created maps Game mods Replays
Attack Surface
A code defect is not a vulnerability unless there is an open attack surface that lets an attacker provide data to it. However, do not patch a vulnerability by simply
putting guard code in the discovered attack surface. There are powerful binary analysis tools available that make it trivial to determine the changes in the code. By only providing a work around for the initially discovered attack surface, you make it easy for attackers to isolate the vulnerable component and trace other surfaces that may provide access to it.
Threat Modeling
Data becomes interesting when it crosses “trust boundaries”. Trust boundaries occur whenever you cross
machines, users, privilege levels, or authors.
Loading the official missions Loading a player created map Loading a player created mod Playing a multiplayer game Viewing a replay in engine Viewing a replay from another user in engine
Threat Modeling
Threat models describe the way the data flows across the application, and highlight where the trust boundaries are crossed. You can consider the threat model to be
a profiler indicating where you should concentrate your efforts in securing the application.
Threat Modeling:Data Flow Diagrams
• Real People• News feeds• Data feeds• Events• Notifications• Etc…
• Function call• Network traffic• Shared memory
• Etc…
• Services• Web Services• Assemblies• DLLs• EXEs• COM object• Etc…
• Database• File• Registry• Shared Memory
• Queue/Stack• etc…
FPS: Context Diagram
GameService
MasterServerList
PlayerRankings
Server
Client Local Player
Local Player
RemoteServer Admin
Leaderboard
FPS: Partial DFD Level 0
GameService
MasterServerList
PlayerRankings
Server
ClientLeaderboard
ReportLeaders
Report Game
Report Score
ReportServers
RequestServer List
ListServers
RequestServer List
UpdateServer List
Update Rankings
GetRankings
Server
Client
RemoteServer Admin
DefaultGameAssets
PlayerCreatedMaps
PlayerCreatedMods
GameSettings
FPS: Partial DFD Level 0ChangeSettings
ReportSettings
ChangeSettings
ManagePlayers
GetSettings
Maps
Assets
ChangedGameFunctionality
TransferMods/Maps
UpdateGame State
ReportSettings
ReportActions
External EntityExternal Entity
ProcessProcess
Data StoreData Store
DataflowDataflow
SS TT RR II DD EE
XX XX
XX XX XX XX XX XX
XX XX XX
XX XX XX
Reference: Primary Threat Chart By Asset
XX
Code Vulnerability:ASSERT
Code Vulnerability:ASSERT Considered Harmful
void Packet::CopyContents( void *buffer, unsigned int
maxSize ){
ASSERT (buffer );ASSERT( ContentsSize() <= maxSize );
memcpy( buffer, Contents(), ContentsSize() );}
Code Vulnerability:ASSERT Considered Harmful What ASSERT is good for?
Checking for coding errors within the same trust level
Checking for code integration defects Finding cases where the assumptions of
one part of the code base have been changed
When is ASSERT dangerous? When it is used to validate untrusted
data sources
A (Very) Basic Introduction to Cryptography
Basic Introduction to Cryptography Cryptography is not a simple subject Even using Cryptography effectively
is not a simple subject Unless you are a skilled
cryptographer, and you present your findings publicly, and they hold up over years of analysis, using cryptographic techniques you invented is at best only a bad idea...
Basic Introduction to Cryptography At the most basic, cryptography
involves secrets; some combination of things that one or all parties involved know, but that no one else does
How effective cryptography is depends on the strength of the secrets, the way in which they are used, and the state of current technology.
Basic Introduction to Cryptography: Confidentiality To defend the confidentiality of data, we
need to ensure that only the appropriate people can decipher the contents.
We could do this with a symmetric key encryption algorithm. That is to say, both the encryption and decryption key are the same. If the key is in fact secure, then only the people
with the key can read the contents, assuming the key is long enough that brute force cracking attempts are not usable.
Basic Introduction to Cryptography: Confidentiality But is confidentiality the only thing
we care about? If the data is intercepted, the bad guy
may not be able to read it, but it can certainly be tampered with.
At best the data that was deciphered would be useless
At worst it would look right, but be wrong
Basic Introduction to Cryptography: Confidentiality To detect whether the data has been
tampered with, we need a separate way to validate that the data was unchanged. MAC (Message Authentication Code)
Generate a hash of the actual data Encrypt the hash with a different shared secret
If the MAC matches the data, then it hasn’t been tampered with. If it doesn’t match, all you know is that the
data was wrong, you cannot repair the data.
Basic Introduction to Cryptography: Key Problems All that the symmetric key
encryption does is verify that the sender was someone who had the secret key. If the encryption key is shipped as part
of the software, the potential sender set is arbitrarily large
If the encryption key is transmitted as part of the game session, it is vulnerable to man-in-the-middle attacks
Basic Introduction to Cryptography: Key Exchange Public Key Encryption provides a
framework for secure and authenticated key exchange In public key encryption, the encryption
keys are asymmetric; each key can encrypt a message that only the paired key can decrypt.
If the public keys of both parties are known, then the symmetric key used for the session can be transferred securely.
Basic Introduction to Cryptography: Key Exchange Why not just use public key
encryption for the data? Public key encryption is computationally
intensive (and therefore slow), especially as compared with symmetric encryption.
What about SSL? SSL authenticates the remote machine to
the user, it does not authenticate the user to the remote machine in general usage
Code Vulnerability:Integer Over/Underflows
Code Vulnerability: Integer Overflows/Underflows
1 bottle of beer on the wall, 1 bottle of beer! Take one down, pass it around, 0 bottles of beer on the wall.
0 bottles of beer on the wall, 0 bottles of beer! Take one down, pass it around, 4294967295 bottles of beer on the wall.
Code Vulnerability: Integer Overflows/Underflows Where does this show up in real applications?
int dataSize = packet->Size() – HEADERSIZE;
if( bufferSize > dataSize ){
memcpy( buffer, &packet->Buffer()[HEADERSIZE], dataSize );
}
What if the size field embedded in that packet is less than HEADERSIZE?
Code Vulnerability: Integer Overflows/Underflows If Chris wants to buy beer by the
case, and each bottle takes 1 unit of storage, calculate how much storage Chris will need…
UInt16 CalcBottles( UInt16 numCases ){
return( numCases * BOTTLESPERCASE );}
What if numCases is 2731?
Code Vulnerability: Integer Overflows/Underflows Ok, so…
UInt16 CalcBottles( UInt16 numCases, bool& overflow ){
UInt32 storageNeeded = numCases * BOTTLESPERCASE;overflow = storageNeeded > MAX_UINT16;
return( (UInt16) storageNeeded );}
Better, but…
Code Vulnerability: Integer Overflows/Underflows
What happens if the number of cases was 2730?Bottle* SysAllocBottleStorage( UInt16 bottles ){
UInt16 bottlesNeeded = (bottles + 31) & ~31;return( MakeBottleRacks( bottlesNeeded ) );
}
This would only be a problem if memory allocation functions padded allocation requests to be boundary aligned.
Which of course, they do.
An Introduction to Static Code Analysis
Finding High Risk Code
Finding dangerous API usage can be done via source code analysis, or by checking the linker information for imports. It is not that difficult to grep for strcpy() Ensuring that developers don’t
immediately write their own version of the dangerous API requires training.
Finding High Risk Code
Commercial source code analysis tools exist to find high risk code patterns (including arithmetic over/underflows) Gimpel Lint (PC-lint and FlexeLint)
Note: If using Lint, be very careful with the use of ASSERT or equivalents to disable Lint warnings
PREfast Included with Visual Studio 2005 Team Edition Driver and Windows Mobile Editions also are
available
Analyzing Changes
Commercial tools exist to analyze and isolate the differences between two versions of an application BinDiff from SABRE Security can also
identify libraries and components that have been previously analyzed.
Attackers are in a position to take advantage of weaknesses that are highlighted in a patch, or that have been found in other applications using the same middleware.
An Introduction to Fuzzing
“Fuzzing”
Fuzzing is the automatic application of malformed data. It can range from sending pure garbage
or flipping random bits to detailed, format or protocol aware intelligent malformation.
“Dumb fuzzing” almost invariably works against unhardened applications.
Games are almost invariably unhardened applications. You do not want to be the low hanging fruit on the application stack.
“Fuzzing”
Simple dumb fuzzing against all of the trust boundaries identified in your threat model will go a long way towards making the application secure, as well as significantly more robust. This includes fuzzing the exposed API of any SDK
you make available for mod developers. We know we will get errors with fuzzed data, what
we care about are access violations, memory spikes above expected norms, and CPU spikes above expected norms.
It is more time consuming to figure out if an access violation is exploitable than it is to fix it, so just fix it.
Integrating Security into the Development Process
Integrating Security into the Development Process
The Principle of Least Privilege Automated compiler protections Dangerous API / Code Practice
Removal Attack surface reduction Threat modeling Fuzzing Security Development Lifecycle
The Principle of Least Privilege
No application should ever demand more privileges than it actually needs to do its work
As a corollary, if you find yourself running with additional privileges, and the platform permits it, rescind them and run minimally privileged
Automated compiler protections There are compiler and Operating
System options which can serve as a defense in depth
/GS or -fstack-protector or equivalent compiler options put protection against overwritten return addresses into the code
/SAFESEH is a linker option which puts protection in place help ensure that the exception handlers are those which were registered by the developer, not by malicious code
/NXCOMPAT is a compiler option which works with the OS and the CPU to limit the ability of malicious code to execute on the stack
Dangerous API / Code Practice Removal There are available replacements for
dangerous API elements, and the dangerous functions can be easily found in existing code.
There are available libraries to check for arithmetic over and underflows.
There are commercial tools for static code analysis for dangerous code practices.
Use of these tools will greatly reduce the vulnerability of your underlying source code.
Attack Surface Reduction
Reducing the Attack Surface makes it harder for code defects to become vulnerabilities, and for vulnerabilities to become exploits.
For any exposed attack surface, ask: Is this used by 80% of the players? Is it open even when it isn’t in use? How can access to this be restricted without
impacting play? Is access to this surface authenticated and
authorized? Are we authenticating the right component?
Threat Modeling Do not overcomplicate your Threat Model
If the Threat Model is looking more like a Call Graph, it is far too complex. A Threat Model should consist of a context, and at most two levels below the context (DFD 0 and DFD 1)
There are Threat Model tools freely available
Building the Threat Model can be done as part of Pre-Production Be sure to update the Threat Model if
assumptions or components change
Fuzzing
There are both free and commercial fuzzing tools available.
Basic dumb fuzzing can be implemented inline in code, simply by randomly flipping bits in a buffer immediately after reading it from the data source.
Apply fuzzing techniques to the high risk data flows found by the Threat Model.
Security Training
SecurityKickoff
Security DesignBest
Practices
Security Arch & Attack SurfaceReview
Use SecurityDevelopment
Tools &Security BestDev & Test Practices
Create Security
Docsand Tools
ForProduct
PrepareSecurity
ResponsePlan
Security
Push
Pen
Testing
FinalSecurity Review
Security Servicing &ResponseExecution
Feature ListsQuality
GuidelinesArch DocsSchedules
DesignSpecifications
Testing and Verification
Development of New Code
Bug Fixes
Code Signing +
CheckpointExpress Signoff
RTM
Product SupportService Packs/QFEs Security
Updates
Requirements Design Implementation Verification ReleaseSupport
&Servicing
ThreatModeling
FunctionalSpecifications
Traditional Software Product Development Lifecycle Tasks and ProcessesTraditional Software Product Development Lifecycle Tasks and Processes
Reference: The Security Development Lifecycle
Questions?
References
Writing Secure Code, 2nd Edition Michael Howard and David LeBlanc Microsoft Press, 2003
Threat Modeling Frank Swiderski and Window Snyder Microsoft Press, 2004
Fuzzing Tools Wikihttp://rtos.trinux.org/secwiki/FuzzingTools
Security Development Lifecyclehttp://msdn.microsoft.com/library/en-us/dnsecure/html/sdl.asp
Best Security Practices in Game Developmenthttp://msdn.microsoft.com/library/en-us/directx9_c/Best_Security_Practices_in_Game_Development.asp
Impact of Software Vulnerability Announcements on the Market Value of Software Vendors – an Empirical Investigation
http://www.heinz.cmu.edu/~rtelang/event_study.pdf
References
Strsafe Library for String Functionshttp://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/resources/strings/usingstrsafefunctions.asp
SafeCRT Libraryhttp://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx
SafeInt Class (C++)http://msdn.microsoft.com/library/en-us/dncode/html/secure01142004.asp
IntSafe Library (C)http://blogs.msdn.com/michael_howard/archive/2006/02/02/523392.aspx
Microsoft Threat Modeling Toolhttp://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx