CS390S week 13: Randomness Pascal Meunier, Ph.D., M.Sc., CISSP November 15, 2006 Developed thanks to the support of Symantec Corporation, NSF SFS Capacity Building Program (Award Number ) and the Purdue e-Enterprise Center Copyright (2004) Purdue Research Foundation. All rights reserved.

Learning objectives  Understand why creating files in insecure directories like /tmp is difficult but useful  Learn why OS-provided function calls help tremendously  Understand the need for good randomness  Learn which OS-provided function calls help provide good random numbers  Learn how to create random file names  Learn a randomness visualization technique  Understand the need for randomness in networking protocols such as TCP

Temporary Files  Space for temporary files is found in directories such as /tmp, /var/tmp or C:\TEMP, where everyone can write  Space may be purged regularly (e.g., "every night, files older than 5 days are deleted") and during reboot  Space used by many UNIX or Windows utilities, installers and programs  UNIX systems are often configured so that this space is not counted as part of user quota –Allow large, temporary jobs

Shared vs Secured Directories  Secured Directories –Solution discussed in previous slides (Part 5)  e.g., temporary directory in user directories in Windows –%userprofile%\Local Settings\Temp –Avoid the problems of shared directories  Most of the problems discussed in these slides don't apply to secured directories –Prefered solution  What if you need or want to use a shared directory? –What are the dangers of using shared directories? –What do you need to do to avoid these problems? –If that's what you want to know keep reading these slides

Race Conditions In Shared Directories  There's a race condition between testing if a file already exists and creating it –Need a unique and unpredictable name to avoid a collision between links and your files or directories  There's a race condition between creating a file and changing its permissions –Permissions initially set by OS based on:  umask (UNIX)  ACLs of parent (Windows) –Are they the desired and correct permissions?

Name Collisions Attacks  What if the name of your temporary file (lock file or other) in /tmp is constant or predictable? –Your program using a lock file may never run or do what it's supposed to!  Run the lock.c example from part A, but this time, create a lock file beforehand... Your program will never get past the lock file test (obviously)  Lock files need to be put where other users can't create files –It's easy to make a symlink pointing to a sensitive file  Symlink attacks are easier if the name of the temporary file is predictable

How Not to Choose a Random Name  Use the process ID  Use the user ID  Use the time of day  Use a counter  Use a bad random number generator  etc...

OS Support for Temporary Files  The following take a filename “template” as input –mktemp - generate temporary file name (unique) –mkstemp - also create the file –mkstemps - generate temporary file name with suffix –mkdtemp - create a directory  Overwrite part of a template to create a unique name  Some of these functions used to create names using parts of the date or process ID, etc... and were insecure

mktemp (1) (3)  Section (1): command line (shell scripts) –BSD/MacOS X: –creates file with mode 0600 unique name  Section (3): C programs –Race condition between getting the name and creating the file! –The program must use "open" with the O_CREAT | O_EXCL flags, and loop until the file is successfully created, or use a different function

Command Line Example  % mktemp "testXXXX" testpnbE % ls -al -rw pascal staff testpnbE

mkstemp  Creates name  Creates file open for reading and writing with mode 0600  Returns a file descriptor  No race condition!  Recommended function  Usage for extremely paranoid people: “Unlink” the hard link pointing to the descriptor immediately afterwards (this is a race condition)  The file still exists but nobody else (except with difficulty, the superuser) can access it

Mini Lab  Take the previous lock.c example  Modify it to use mkstemp to generate a temporary file with a unique name  Of course, the temporary file created that way is not a lock file anymore, and would be used to store temporary data instead

Windows Shared Directories  No equivalent to mkstemp()  GetTempFileName –Creates names by incrementing a counter! –Predictable file name  Race condition between getting the name and creating the file –Attacker could create the file to prevent you from using it –If you use the CREATE_ALWAYS flag, see next slide  Under Windows, you have no choice but to write your own function  Still a race condition, limitation due to lack of OS support (use secured directories instead)

Windows CreateFile Problems  Recommended use with the "CREATE_ALWAYS" flag is dangerous –"CREATE_ALWAYS" flag recommended by MSDN, Howard and Leblanc 2003  Overwrites the file  Does not set the security descriptor specified by the SECURITY_ATTRIBUTES structure –Do the SECURITY_ATTRIBUTES matter to your application?  Perfect opportunity to trick you into overwriting a sensitive file –e.g., with a hard link –Can't use the flag to not follow reparse points –Note that links being uncommonly used in Windows FS won't prevent an attack from succeeding

Windows CreateFile  TRUNCATE_EXISTING will follow a hard link and could truncate something else than intended  Use "CREATE_NEW" –"The function fails if the specified file already exists. " (MSDN) –You need to check for errors and loop until the file is successfully created

GetTempPath  MSDN recommends that software use the GetTempPath function to get the location of the temp dir, but this is dangerous  Checks for the existence of environment variables in the following order and uses the first path found: 1. The path specified by the TMP environment variable. 2. The path specified by the TEMP environment variable. 3. The path specified by the USERPROFILE environment variable. 4. The Windows directory."  Are the environment variables safe to use? –Probably not unless you set them yourself

Exercise (Windows): Creating Temporary Files  Go to brary/en- us/fileio/base/creating_and_using_a_temporary_file.asp  Discuss things that you would do differently, compared to the example, when creating a temporary file in Windows –Find the race condition (hint: MoveFileEx)

Exercise Answers  Possible answers: –They used the CREATE_ALWAYS flag instead of CREATE_NEW  Add a loop until success –Use randomly generated file names  How to do that on Windows? (see next slides)

The Need for Random Numbers  Unique file or directory names  Session IDs that carry proof of authentication (nonces), passwords  Games (data, behavior, opponent generation, character generation)  Encryption  Cryptographic protocols

How Random Numbers Are Generated  Linear Congruential Generators –Simple way to generate pseudo-random numbers –Easily cracked –Produce finite sequences of numbers –Each number is tied to the others –Some sequences of numbers will not ever be generated  Cryptographic random number generators  Entropy sensors (i.e., extracted randomness)

Seeded Random Number Generators  Pseudo-random generators depend solely on a seed, which determines the entire sequence of numbers returned  How random is the seed? –Process ID, UserID: Bad Idea –Current time: if you’re running NTP (Network Time Protocol) all systems are synchronized up to some precision. If you use the time, maybe I can guess which seed you used (microsecond part might be difficult to guess, but is limited)

How to Cheat At Random Number Generation  Find a seed that will produce the numbers you want  Seed the generator with it  Convince someone: "it's random, see?" –RPG Character generation, etc...

Roll Your Own Generator?  What matters is not only the average and the variance of the numbers generated  All sequences of numbers must be possible  LCGs travel definite, limited “paths” through the universe of possible sequences  Need to incorporate entropy as it becomes available  Need to avoid betraying the internal state of the generator...  It's difficult to do correctly

Which Generator to use?  Read description, avoid Linear Congruential Generators such as these: –“C” rand(3) –rand (Windows CE, Visual C++, Visual Basic, etc...) –Perl rand –C# Random –PHP rand

Good Generators  Hardware-based –Noise  Cryptographical quality software, entropy-seeded –Fast, secure  Pure Entropy –Random timing of events  Packets  Mouse movement, clicks  Keyboard –Slow

Linux/UNIX Devices  /dev/random: –MacOS X: same as urandom –Linux: this is a blocking call that returns only when sufficient entropy has been captured –Good for seeding pseudo-random number generators  /dev/urandom: –Implements a fairly complex algorithm that varies between “random” and a well-seeded LCG depending on the availability of entropy –Non-blocking call –Try "cat /dev/urandom"

Portability  FreeBSD, OpenBSD, NetBSD compatible  Several projects ported the functionality to Solaris, HP-UX, AIX, IRIX  MacOS X implements Yarrow for both random and urandom (so the behavior of “random” is unexpected).

Windows  Windows developers must use the function CryptGenRandom(), which uses the same idea as /dev/urandom  There is no directly accessible entropy collector provided by the OS –Reference: "Secure Programming Cookbook", section 11.4 (Viega et al.)

Randomness Visualization  Strange attractors –Zalewski 2001, 2002 "Strange Attractors and TCP/IP Sequence Number Analysis"  Given a sequence of numbers s[n] compute: –x[n] = s[n-2] - s[n-3] –y[n] = s[n-1] - s[n-2] –z[n] = s[n] - s [n-1]  These are the x,y,z coordinates of a point –Plot them to see hidden dependencies

Cisco IOS 12.2 (Zalewski 2002)

IRIX (Zalewski 2002)

Windows XP (Zalewski 2002)

ISN Vulnerabilities  Predictable –Symantec Raptor Firewall 6.5 and 6.5.3, Enterprise Firewall and 7.0, VelociRaptor Models 500/700/1000 and 1100/1200/1300, and Gateway Security 5110/5200/5300 generate easily predictable initial sequence numbers (ISN), which allows remote attackers to spoof connections.  CAN –Cisco switches and routers running IOS 12.1 and earlier produce predictable TCP Initial Sequence Numbers (ISNs), which allows remote attackers to spoof or hijack TCP connections.  CVE –etc...

TCP RST Flag  TCP reset (RST) flag is used to abort TCP connections, usually to signify an irrecoverable error –Receiver deletes the connection, frees data structures  RST messages are accepted only if they fit inside the sequence number window –Prevents delayed RST messages from previous connections to affect the current connection

TCP RST Attack  Send a RST (TCP RESET flag) packet with a spoofed IP address to either side of a valid connection –Need to guess a sequence number inside the appropriate window  Or sniff traffic to know which number to use –The range can be guessed fairly efficiently for RST attacks –Sequence numbers: 32 bits –Window size: up to 16 bits –Number of guesses = 16 bit address space  RST attempts, ~ 4 min on DSL connection  Faster connection or zombies, faster RST  This is the brute force RST attack

TCP Session Hijacking  Idea: all that’s required to mess up someone else’s TCP session is guessing or knowing the sequence numbers for their connection. –Only need to fall within the needed range, exact guess not needed  Send a spoofed IP packet, with a TCP payload that inserts data  Blast the legitimate client off the net –Replies are still sent to client but client is incapacitated –You do not get to see replies: “blind” hijacking  Unless you can sniff traffic, in which case the sequence numbers to use are also known

Questions or Comments?

About These Slides  You are free to copy, distribute, display, and perform the work; and to make derivative works, under the following conditions. –You must give the original author and other contributors credit –The work will be used for personal or non-commercial educational uses only, and not for commercial activities and purposes –For any reuse or distribution, you must make clear to others the terms of use for this work –Derivative works must retain and be subject to the same conditions, and contain a note identifying the new contributor(s) and date of modification –For other uses please contact the Purdue Office of Technology Commercialization.  Developed thanks to the support of Symantec Corporation

Pascal Meunier Contributors: Jared Robinson, Alan Krassowski, Craig Ozancin, Tim Brown, Wes Higaki, Melissa Dark, Chris Clifton, Gustavo Rodriguez-Rivera, Michael Howard