INTRODUCTION:
The security threat posed by insiders is often underestimated. According to an IBM study, 32% of attackers are insiders and 24% are “inadvertent actors” (e.g. people making mistakes that lead to a system breach or incorrect behavior.) One such class of insider attack is malicious code added during development that allows for future exploitation. Advanced static analysis tools can detect these within source during development as well as binary code before it gets deployed. In addition to existing detection for security vulnerabilities, this post also talks about specific security vulnerability checks to detect certain insider attacks.
Related:
- 2011 CyberSecurity Watch Survey: How Bad Is the Threat?
- Common Sense Guide to Mitigating Insider Threats 4 th Edition
- Insider attacks and static analysis: How to spot the signs with three important new analyses
What are insider attacks?
Insiders are people working inside the secure perimeter either as users, developers or other trusted personnel. The big difference from regular cyber-attacks is the attacker is an individual who has explicit permission to access a device or system. The attack surface for insiders is larger than for outsiders. According to the SEI, 21% of electronic crime was perpetrated by insiders and 43% of respondents to their survey had experienced at least one insider attack.
Insider “attacks” might be due to unintentional mistakes or intentional malice by disgruntled employees. The attacks that are of interest in this post are those that take the form of a deliberately-planted vulnerability or capability than can be triggered in the field on demand, or on a schedule predetermined by the attacker. In the same SEI survey, 37% of insider attacks were enabled by “virus, worms or other malicious code.”
Using Advanced Static Analysis to Detect Possible Insider Attacks
Advanced static analysis tools can detect different classes of security vulnerabilities such as buffer, numeric and stack overflows, command injection, and use of insecure library functions. The tools can also trace data flow from outside sources to the vulnerable code (tainted data analysis), which leads to a verifiable attack vector. These types of vulnerabilities can be written intentionally and concealed so that they are undetected during development, so that an attacker can use them in a later exploit. A priori knowledge of these vulnerabilities would be a special case of a zero-day exploit known only to the insider. Therefore, it’s important to detect and remove these types of vulnerabilities through proper security measures throughout the software development life cycle, something discussed in a previous post.
Binary analysis for finding attacks
CodeSonar’s binary code analysis technology is capable of analyzing stripped optimized executables; it can find roughly the same classes of defects that can be found in the source code. CodeSonar’s new integrated analysis is capable of analyzing source and binaries simultaneously. This is useful in cases where you have source code for most of the project, but only binary libraries for some components.
GrammaTech CodeSonar provides additional malicious code detection for detecting dangerous process creation, use of chroot, and possible time bombs..
Examples
The following examples are specific malicious code checkers available in CodeSonar for detecting certain types of insider threats.
Untrusted Process Creation
Process creation is always potentially dangerous, especially if it is possible to manipulate the process name or its parameters (this would amount to a command injection vulnerability.) CodeSonar detects untrusted process by detecting calls that create processes and checking the process name against a whitelist (known acceptable processes) or blacklist (potentially dangerous processes.) These lists are configurable but the default blacklist includes well known, potentially dangerous commands. The example below produces a warning with the shell (sh) command but not with “myprocess” which isn’t in the blacklist.
#include <stdlib.h>
#include <stdio.h>
void ut_proc(const char *command) {
FILE *pipe_file;
if (pipe_file = (FILE*)popen("/usr/bin/myprocess","r")){
/* not blacklisted */
pclose(pipe_file);
}
if (pipe_file = (FILE*)popen("/usr/bin/sh","r")){
/*'Untrusted Process Creation' warning issued here */
pclose(pipe_file);
}
}
CHROOT Without CHDIR
Issuing the chroot() (change process root directory) Unix/Linux function is potentially dangerous if malicious code can exploit the situation to access files in other parts of the system. A best practice is to issue the chdir() (change current process directory) command right before or after chroot(). In the example below, there is no warning raised when chdir() isn’t successful, and the process is aborted. However, later in the code a warning is issued because the call to chdir() is dependent on a check of the variable fname.
#include <unistd.h>
#include <stdio.h>
int chroot_no_chdir(const char *fname, char *buf){
FILE *localfile;
int bytesread=0;
if (chroot("/downloaddir") == -1){
/* 'chroot without chdir' not issued here, call unsuccessful */
abort();
}
if (fname){
if (localfile = fopen(fname, "r")){
bytesread = fread(buf, 1, sizeof(buf), localfile);
fclose(localfile);
}
if (chdir("/")==-1){
/* warning here: chdir() is only called if fname != NULL */
return 0-bytesread;
}
}
return bytesread;
}
Potential Timebomb
Time bombs are possible in code that uses and checks for time values from the system clock. Reasonable checks for time are acceptable but code that doesn’t use a value relative to the current time, such as a hardcoded value may be “waiting” for a specific time and date to execute malicious code. In the example below, the code that isn’t checking time against a retrieved from the time() system call is suspicious and flagged.
#include <time.h>
void misc_timebomb(void){
time_t deadline = 1893456000;
time_t now = time(NULL);
if (now > time(NULL)){
/* ok: time value compared against another time value */
/* ... */
}
if (now < deadline){
/* 'Potential Timebomb' warning issued: time value compared */
/* against non-time value */
return;
}
/* An inside attacker could put malicious code here:
it would only be executed once the deadline was past. */
}
CONCLUSION:
Insider threats in the form of malicious code written by insiders are a significant, but often overlooked, source of cyberattacks. Advanced static analysis tools can detect intentional malicious code using security vulnerability analysis. GrammaTech CodeSonar detects different types of security vulnerabilities in addition to tainted data flow analysis. CodeSonar also includes checkers for specific malicious code types that help prevent exploitable code from reaching the finished product.
Like what you read? Download our white paper “A New Era of Software Forensics with Static Analysis” to learn more.
{{cta(‘d83151ce-f61a-4b62-838a-61d35718bed3’)}}
