Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 SEC835 Secure Programming PREVENT Information Leak Vulnerabilities.

Similar presentations


Presentation on theme: "1 SEC835 Secure Programming PREVENT Information Leak Vulnerabilities."— Presentation transcript:

1 1 SEC835 Secure Programming PREVENT Information Leak Vulnerabilities

2 2 The Sensitive Bits  Knowing what is sensitive is just as important as how you handle it. This isn’t a complete taxonomy, but here are some of the tokens to track: –Login Credentials Usernames, passwords, session identifiers, etc. –Personally Identifiable Information Full names, phone numbers, addresses, –Financial Information Credit Card Numbers, Bank Card PIDs, Account Figures, –Individual health data Sicknesses –Cryptographic Tokens Keyphrases, RNG seeds, private keys, etc.

3 3 Information Leak When attempting to extract sensitive data, attackers will go after: –The Application Binary –The Application’s Memory at Runtime –The Application’s Saved Resources (i.e. anything that is written down) Other sources of information leak: –Error messages –Audit log –User’s Interface

4 4 The Threats to the Binary  Binary can be viewed by  ASCII Text Extraction  Hex Viewing  Disassemblers  To prevent viewing you must wipe data from memory. That is not an easy thing, because data may reside not only in cache but also in a hard disk, or even on USB drive  Recommended cleansing  Wipe must be done more than one time  Provide multiple one-by-one overwrites for each byte of information.  Use zeros, or even better, use random characters  Make sure that the data is wiped on any circumstances (positive exit or error exit)

5 5 The Threats to Memory  Data in cache memory may be read through  Stack Traces  Report of the active stack frames at a certain point in time during the execution of a program. Stack traces can be viewed with system calls  Debuggers  Tools used to test software  Process Inspections  Tools to control processes  Page files  Data pages stored in the secondary memory (virtual memory)  Core Dumps  The recorded state of the working memory of a program at a specific time

6 6 The Threats to Saved Resources  Data recorded to a persistent store can be accessed by  Text/Hex Editors  Registry Editors/Monitors  Brute Force Deciphering  File Format Reverse Engineering

7 Prevent data leakage – PCI DSS Payment Card Industry (PCI) standards require preventing credit card data leak through the application –GUI – do not display credit card numbers without masking –Data store – The full content of any track from the magnetic stripe must not be stored The card verification code must not be stored. The personal identification number (PIN) must not be stored. The Primary Account Number (PAN) will always be stored as unreadable. Cardholder data will be encrypted –Data in transit Cardholder data must be encrypted in transit. –Application All data inputs must be validated. Secure error handling must be implemented. –Memory Erase cardholder data from electronic media immediately after usage. 7

8 8 Prevent data leak from memory Immutable objects are difficult to wipe –Mutable objects are preferable  Java’s garbage collection cannot be relied upon to clean up values stored in memory. Until its threshold is reached, heap-inspection attacks remain possible. Force a clean up of strings and arrays explicitly to reduce the likelihood of exposure.  Cleaning up values in C/C++ requires tracking malloc()/free() operations.

9 9 Cloning, serialization and Childs  Both cloning and serialization open the security hole that allows an attacker to instantiate the object beyond the constructor.  Avoid serialization  Prevent the ability to instantiate uncontrolled child classes by finalizing classes explicitly  Finalizing classes and methods restricts the ability of the attacker to extend valid code in dangerous and unforeseen ways. // Sample authentication class // Made public to support authentication // in apps that use this library final public class Authenticator { final public void CheckCredentials(…) {} }

10 10 Disable Cloning  Java Object’s support cloning implicitly (via an inherited clone() method).  Disable cloning explicitly // stub code for disabling clone operations... private final void clone() throws java.lang.CloneNotSupportedException { throw new java.lang.CloneNotSupportedException(); }...

11 11 Inner Classes  Translated into bytecode, inner classes become accessible to any class in the package and the enclosing class’ private fields become non-private, permitting full access from the inner class. This makes inner classes untrustworthy for security- related tasks and/or sensitive data handling.

12 12 Control Visibility  Every class, method and variable that is not private provides a potential entry point for an attacker. [Java]  Ideally, make as many elements as possible “private”, and implement accessor (get/set) methods;  Implement authorization checks for those methods.

13 13 Package Scope  While package scope does make sense from an operational standpoint, it is not a suitable security measure.  Attackers can access package-private fields simply by adding their own class to the the Jar file.  Classes, methods, and variables that are not explicitly labelled as private or protected are still accessible within the same package.

14 14 Static Variables  Static variables are attached to the class, not the instance (object), and therefore can be found by any other class, including a class placed by a malicious attacker (seeking static key values, passwords, etc.).

15 15 Avoid Core Dumps Data from memory can be swapped in a page file or in a core dump –Avoid core dump –Clean page files  When a core dump occurs, the state of a program in memory is written to disk, and this may include sensitive data that could be extracted as text strings.  If your language allows, lock memory in order to prevent memory dumps on a crash (C can do that)  Keep in mind this may not be desirable in development instances or in certain production cases where the debugging information is needed.  Note: If a core dump captured a sensitive value and wrote it to disk, the standards for securely wiping (overwriting) that core dump must be observed.

16 16 Memory Locks  Operating systems will often save pages of memory to disk, in order to free up RAM. These pagefiles might provide attackers access to sensitive data via ASCII strings.  If you can, prevent swapping of memory to disk (C can do that)

17 17 Protect from information leakage summary Restrict visibility –minimum of public properties, –avoid accessibility inside the package –avoid static variables and inner classes Control object instances –avoid cloning and serialization Care about dumps and file pages –Lock dumping or file pages store Wipe data from memory –Overwrite memory more than one time, do it byte-by-byte –Cache memory must be overwritten by the program –Files and traces on disks must be overwritten by the specialized utilities, for example sdelete Avoid accidental leak from GUI, logs, error messages, etc.

18 Testing for information leak The companies perform testing for information leak by going through static analysis or peer review of the code Often 3 rd party service is used to perform static analysis Accidental leak may be also discovered by functional testing 18

19 19 Conclusion  While it may not be possible to keep sensitive data away from prying eyes all of the time, it is at least possible to make it difficult to. (Making it extremely difficult to obtain sensitive data often discourages all but the most determined individuals.)  Unfortunately, eliminating all traces (secure wiping) of sensitive data remains a tough challenge for programmers.

20 20 Exercise Read the article Review cases of accidental leaking of information On your reference spreadsheet, make short notes in regards to: –How accidental leak of information may happen (comments for I3) –How to prevent information leak (comments for Cells A12-14 )


Download ppt "1 SEC835 Secure Programming PREVENT Information Leak Vulnerabilities."

Similar presentations


Ads by Google