Ever wondered why a pocket torchlight application in your cell phone needs to read your location and needs to access your contacts and e-mail?
Reverse engineering can be used to assess security of a product and to answer questions such as:
- Does the product contain any malicious code?
- Are cryptographic algorithms in harmony with NIST standards?
- Does the product use any dangerous APIs such as strcpy and is therefore prone to buffer overflow?
- Is the product vulnerable to injection?
- Why the product communicates over the Internet and what data it sends out?
Malicious code
Not every program was written with intention to benefit its users. We might have even incidentally ran such a program. What the program did to your computer? Did it send our data somewhere? Did it install a backdoor into our computer? Reverse engineering of the program can answer these questions!
Cryptographic algorithms
Xor is the most favorite beginner’s encryption algorithm. Xoring data is simple and fast and can be even be used to encrypt data well — the only glitch is that the key used to xor the data with must be i) true randomly generated, and ii) used only once. Should these two criteria are fulfilled, we’re talking about Vernam cipher or One time pad. Unfortunately, we have often seen both violated resulting in dangerous cryptographic algorithms used and data stored in an insecure way.
NIST and other organizations have issued standards recommending safe cryptographic algorithms, along with their minimal key lengths. Using proper algorithms and properly long keys still does not need to ensure security, if the key lifecycle is broken because of eg. bad key storage. Reverse engineering can help us to discover which algorithms are used in a product and answer how are its keys generated, stored, used, and destroyed, and whether this approach is fine or not.
Dangerous APIs
{
char buffer[100];
printf("Hello: %s\n", gets(buffer));
return 0;
}
Ever used the gets function in your program? This function is the worst of the string manipulation functions, as it cannot be used in a secure way. Using this function in your program makes your program vulnerable to buffer overflow. When buffer overflow occurs, data is written past the end of a buffer. The buffer can be allocated either on the heap (a heap buffer overflow) or on the stack (stack buffer overflow). Both heap and stack have their structure and this structure is corrupt by writing user input past end of a buffer. A usual consequence of this is a crash of the application. When the input is properly crafted and such input is called an exploit, it can lead to execution of payload contained in the exploit and hijacking of the application by the attacker. What a hijacked application can then do then only depends on its privileges.
Reverse engineering can examine APIs used by the program and look for APIs like that. The analysis can be either performed on the assembly language or decompiled code level – then we are talking about black box analysis and reverse engineering, or can be performed on the real source code – then we are talking about white box analysis and code review.
Injection Vulnerabilities
Injection vulnerabilities are the most common vulnerabilities in OWASP Top 10 2013. The vulnerability is rooted in improper sanitization of input data. When the input validation is insufficient, the attacker can then abuse it and inject its own code into the application’s code and force the application to execute it. The most prominent are SQL injection and Cross-Site Scripting vulnerabilities (#1 and #3 in the Top 10). The product is understood as a black-box and reverse engineering studies how data flows through eg. SQL query functions and whether it is possible to perform injection.