3. Tool: FindBugs
➢ FindBugs uses static analysis to inspect Java bytecode for occurrences of bug patterns. Static analysis means that
FindBugs can find bugs by simply inspecting a program's code: executing the program is not necessary.
➢ FindBugs looks for bugs in Java programs. It is based on the concept of bug patterns. A bug pattern is a code idiom
that is often an error. Bug patterns arise for a variety of reasons:
➢ Difficult language features
➢ Misunderstood API methods
➢ Misunderstood invariants when code is modified during maintenance
➢ Garden variety mistakes: typos, use of the wrong boolean operator
➢ Matched the following CWEs:
○ 89
○ 395
○ 502
○ 821
5. Tool: Java Decompiler
➢ The java decompiler aims to develop tools in order to decompile and analyze Java 5 “byte code” and later versions.
➢ It has four different options in which you can download to utilize the tool:
○ JD-Core
○ JD-GUI
○ JD-Eclipse
○ JD-IntelliJ
➢ JD-GUI:
○ - a standalone graphical utility that displays Java source codes of “.class” files. Ability to browse the
reconstructed source code with the JD-GUI for instant access to methods and fields.
➢ Matched the following CWEs:
○ 360
○ 484
○ 545
6. 14 CWEs on Java
1. CWE-395: Use of NullPointerException Catch to Detect NULL Pointer Dereference**
2. CWE-360: Trust of System Event Data**
3. CWE-821: Incorrect Synchronization**
4. CWE-484: Omitted Break Statement in Switch**
5. CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')**
6. CWE-545: Use of Dynamic Class Loading**
7. CWE-502: Deserialization of Untrusted Data**
8. CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
9. CWE-543: Use of Singleton Pattern Without Synchronization in a Multithreaded Context
10. CWE-103: Struts: Incomplete validate() Method Definition
11. CWE-497: Exposure of System Data to an Unauthorized Control Sphere
12. CWE-299: Improper Check for Certificate Revocation
13. CWE-496: Public Data Assigned to Private Array-Typed Field
14. CWE-767 Access to Critical Private Variable via Public Method
**Notes Exploits Shown in Presentation
7. CWEs: How to Exploit
CWE-395: Use of NullPointerException Catch to Detect NULL Pointer Dereference
➢NullPointerException has the potential to be malicious since a programmer
should not be running into this code.
➢This is only acceptable if the code is part of a test harness that supplies
unexpected input to the classes under test.
➢It is a bad practice to catch NullPointerException due to the fact that a program
explicitly throws a NullPointerException to signal an error condition.
Bad Code:
https://cwe.mitre.org/data/definitions/395.html
https://www.owasp.org/index.php/Catch_NullPointerException
8. Example of CWE-395: Use of NullPointerException
Catch to Detect NULL Pointer Dereference
9. CWEs: How to Exploit
CWE-360: Trust of System Event Data
➢This can simply be malicious to the end-user because events cannot be trusted.
➢Events often does not have any type of authentication framework to allow them
to be verified from a trusted source.
➢One should not trust the system-event information because if commands are
executed based on trust then they could potentially take actions based on a
spoofed identity. Bad Code:
https://cwe.mitre.org/data/definitions/360.html
11. CWEs: How to Exploit
CWE-821: Incorrect Synchronization
➢The software utilizes a shared resource in a concurrent manner but it does not
correctly synchronize access to the resource.
➢It modifies and reads the applications data and alters the execution logic.
Basically it affects integrity and confidentiality.
➢It can be malicious if the attacker can influence the source code the end-user is
sharing.
https://cwe.mitre.org/data/definitions/821.html
13. CWEs: How to Exploit
CWE-484: Omitted Break Statement in Switch
➢Write a switch statement
➢Don’t include a switch or break statement between cases.
➢This will cause the code to execute on multiple conditions instead of one which
can cause malicious code to be inserted
http://cwe.mitre.org/data/definitions/484.html
Bad Code:
Good Code:
15. CWEs: How to Exploit
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
➢SQL injection used to modify a web site to serve malicious code
➢Can bypass the requirement to only return items owned by authenticated user
➢Shell command execution in MS SQL
http://cwe.mitre.org/data/definitions/89.html
16. Example of CWE 89: Improper Neutralization of
Special Elements used in an SQL Command ('SQL
Injection')
17. CWEs: How to Exploit
CWE-545: Use of Dynamic Class Loading
➢Dynamically loaded code has the potential to be malicious.
➢When it can be introduced in the architecture and design and implementation.
➢Avoid the use of class loading as it complicates code analysis.
https://cwe.mitre.org/data/definitions/545.html
19. CWEs: How to Exploit
CWE-502: Deserialization of Untrusted Data
➢This exploit deserializes untrusted data without sufficiently verifying that the
resulting data will be valid.
➢Exploit can be introduced during Architecture and Design and Implementation
➢To avoid security issues with the data a hash-based message authentication
code could be used to ensure that data has not been modified.
https://cwe.mitre.org/data/definitions/502.html
Bad Code:
Good Code:
One of the key things that a Java programmer should not run into is the NullPointerException. It is a horrible practice to even catch the NullPointerException because a program might be programmed to explicitly throw the NullPointerException to signal an error condition. The only way any code should catch this CWE is if it were to be a test condition to catch the null pointer exception. The NullPointerException can be caught in three languages which are Java, C++, and C. This particular CWE is the parent to six different CWEs which are CWE 388 Error Handling, CWE 389 Error Conditions Return Values Status Codes, CWE 705 Incorrect Control Flow Scoping, CWE 755 Improper Handling of Exceptional Conditions, CWE 851 CERT Java Secure Coding Section 06 Exceptional Behavior (ERR), and CWE 962 SFP Secondary Cluster: Unchecked Status Condition. The potential mitigation is in the phases of Architecture and Design with implementation. The code above is an example of which should only be in a test environment. Caching the NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer. The only acceptability to this is if the code is part of a test harness in which supplies unexpected input to the classes under the test.
Events are a messaging system which may provide control data to programs listening for events. Events do not have any type of authentication framework to allow them to be verified from a trusted source. They are security based on event locations that are insecure and can be spoofed. For example, I could create a picture on a website that you can click on and by you clicking on it I could spoof your identity. The scope of this covers integrity, confidentiality, availability, access, and control. The effect to this scope is that of one trusts the system-event information and executes commands based on it, one could potentially take actions based on spoofed identity. This has a very high likelihood to be exploited. Due to there is no authentication framework for these messages .The mitigations that are potential lye in the phase of architecture and design which means to never trust or rely any of the information in an Event for security. This particular CWE is the parent of CWE 422 Unprotected Windows Messaging Channel (‘Shatter”), and is the child of CWE 345 Insufficient Verification of Data Authenticity, and CWE 949 SFP Secondary Cluster: Faulty Endpoint Authentication. This is applicable to all languages.
Incorrect synchronization occurs when a source that is being shared and has not been correctly synchronized with the resource. This can lead to the resource being in an endless state of confusion, which may lead to being to some unexpected and insecure behaviors. Especially if the attacker can influence the shared resources. Incorrect synchronization is a child of CWE-662, improper synchronization. Improper synchronization occurs if software attempts to use a resource exclusively, but does not or incorrectly prevents the use of that resource by another thread or process. This leads to the modification and reading of application data which also alters the execution logic. The parents of incorrect synchronization are CWE-572, call to thread run() instead of start(), and CWE-574, EJB Bad Practices: Use of Synchronization Primitives. CWE-572 is caused when a programmer uses run(), they are not really running the program. In reality the program will execute the run() method versus actually running the call object for start [start()]. As for CWE-574, in JavaBeans specifications, it requires that every project follows the same set of programming guidelines. This requirement is very important if the programmer wants to make the software source code portable to JavaBean installations on other systems. The potential mitigations is in the phase of implementation. This is where the you use the start() method instead of the run() method.
The Omitted Break Statement in Switch statements is one that can be easily exploited but one that can be prevented if one takes their time to check the code before executing it. This is a vulnerability found in C++, C#, .NET, PHP and Java code. This CWE is the child of CWE 398 Indicator of Poor Code Quality, CWE 670 Always-Incorrect Control Flow Implementation, CWE 962 SFP Secondary Cluster: Unchecked status condition, and member of CWE 884 CWE Cross-section. This vulnerability occurs when a break or switch statement is omitted between statements. This causes the code to exhibit fall through characteristics. This means that code that was intended to be executed will not be run correctly or at all. There are times where the break statement is intentionally not used to allow the code to fall through. This is not recommended and is still seen as an error in coding. They suggest when omitting a break statement an “if statement” should be used should be used to clarify the meaning of the code and makes sure it executes properly. If you use the fall-through capabilities make sure that you have clearly documented this within the switch statement and ensure that you have examined all the logical possibilities.
Software constructs all or part of an SQL command using externally-influenced input without correctly neutralizing special elements that could modify the intended SQL commands. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of system commands. SQL injection has become a common issue with database-driven web sites. Flaws in the software can be easily detected and exploited. This is because SQL makes no real distinction between control and data planes, no matter the size of user base involved. This affects all languages and has a very high likelihood of exploitation. Database server is the technology that it hits. What this has a possible outcome is the following. Loss of confidentiality that may allow sensitive database data to be read, also loss of access control may allow access control measures to be bypassed. Last option is loss of integrity may allow to be modified, delete, or even delete the database itself. May occur at any time of introduction. Ways to detect this is using automated static analysis tools, dynamic tools and techniques that interact with the software, manual analysis bytecode and binary weakness analysis, database web-application and web services scanners, fuzz tester/framework-based fuzzer, and manual source code review/focused manual spot-check analysis of source.
Dynamic class loading has the potential to be malicious when it is wrote during the architecture and design phase and also in the implementation phase. This is only for Java. The technical impact executes an unauthorized code or command. An attack executes malicious code that they have included in the loaded class. The code can be executed without calling a specific method if the malicious code is hidden within the static class initializer. In order to avoid this use of the class loading as it greatly complicates code analysis. When the application requires dynamic class loading, it should be well understood and documented. All classes that may be loaded should be predefined and avoid the use of dynamically created classes from byte arrays. There is a relationship between a few other CWEs which are 485, 991 and 884. CWE 485 is insufficient encapsulation, CWE 991 is SFP secondary cluster: tainted input to environment, and CWE 884 is a CWE cross-section. Example of code that would allow for dynamically load a class is the following
String className = system.getProperty(“customerclassName”);
Class clazz = Class.forName(className);
Just make sure that you name what can be loaded so that this error does not happen for your program.
Deserialization of untrusted data happens when untrusted data without sufficiently verifying that the resulting data will be valid. It is convenient to save serialize objects for communication or to use for a later date. Desterilized data or code can be modified without using the provided accessor functions if it does not use cryptography to protect itself. Any cryptography would still be client-side security—which is a dangerous security assumption. Data that is untrusted cannot be trusted to be well-formed. Terms that can be associated are marshaling, unmarshaling pickling and unpickling. The time that the issue can be imputed is during architecture and design and implementation. The different languages that can be effected are Java, Ruby, PHP, Python and Language-independent. Common consequences under integrity attackers can modify unexpected objects or data that was assumed to be safe from modification. Under availability if a function is making an assumption on when to terminate, based on a sentry in a string, it could be easily never terminate. Under authorization and other code could potentially make the assumption that information in the deserialized object is valid. Functions that make this dangerous assumptions could be exploited. Ways to make sure that this does not happen are the following. If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe. Last option is to explicitly define final readObject() to prevent deserialization.
