Hulp
Deze pagina aan uw boek toevoegen
Boek weergeven (500 pagina's)
Pagina's suggererenSoftwareSecurity2014/Group 11/Code Scanning
Scanners
Fortify
We decided to go through each issue that fortify presents us and do a short analyse to what the issues mean to our 1B verification.
(Erik: Nice to see that you have gone through all these warnings, but your discussion of them is sometimes a bit cryptic, or in not very clear English. My interpretation of V4 and V9 is quite a bit narrower than yours. Eg I don't see why using a weak hash would impact V4 or V9.)
Categories
| Category | Reasoning |
|---|---|
| Access Control: Database | (12 issues found) Concerns the use of a broad range of information security controls to protect databases. This is an issue because the use of "@", if the credentials fail, an error is printed and cannot be trapped with a try/catch.
for eg in $this->result = @mysql_query( $query, $this->dbh ); "@" suppress error messages V4 and V9 (Erik:This last part is a bit cryptic; you mean it is related to V4 and V9?) |
| Code Correctness: Regular Expressions Denial of Service | (81 issues found) A poorly written regular expression can be exploited so that a relatively short attack string (fewer than 50 characters) can take hours or more to evaluate. In the worst-case scenario, the processing time is actually exponential to the number of characters in the input string, meaning that adding a single character to the string doubles the processing time.
There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating repeating and alternating overlapping of nested and repeated regex groups (regular expression). This defect can be used to execute a DOS (Denial of Service) attack. No connection with V4 or V9 |
| Command Injection | (71 issues found)
The purpose of the command injection attack is to inject and execute commands specified by the attacker in the vulnerable application. Fortify explains: "Command injection vulnerabilities take two forms: - An attacker can change the command that the program executes: the attacker explicitly controls what the command is. - An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means. In this case we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when: 1. Data enters the application from an untrusted source. 2. The data is used as or as part of a string representing a command that is executed by the application. 3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have. " This is connected to V4 and also with V9 |
| Cookie Security: Cookie not Sent Over SSL | (24 issues found) The program creates a cookie without setting the secure flag to true, so it's not going to be sent over secure HTTPS. Sending cookies over an unencrypted channel can expose them to network sniffing attack and possibly impact V4 and V9. |
| Cookie Security: HTTPOnly not Set | (24 issues found) If supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker's website. But we have HTTPOnly Not Set that is connected with V4 but not directly with V9. |
| Cookie Security: Persistent Cookie | (25 issues found) If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data - especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users' privacy.
Connections with V4 and V9. (Erik: I'd say that this is a V3 - session - issue) |
| Cross-Site Request Forgery | (120 issues found) Cross-site request forgery (CSRF) is a common and serious exploit where a user is tricked into performing an action he didn’t explicitly intend to do.
Connected with V4. |
| Cross-Site Scripting: Persistent | (485 issues found) Cross Site Scription does not directly relate to Access Control vulnerabilities of the server application, but has potential effect on vulnerabilies in the User Agent that interacts with Wordpress. |
| Cross-Site Scripting: Poor Validation | (1049 issues found) Cross Site Scription does not directly relate to Access Control vulnerabilities of the server application, but has potential effect on vulnerabilies in the User Agent that interacts with Wordpress. |
| Cross-Site Scripting: Reflected | (1469 issues found) See above. |
| Dangerous File Inclusion | (19 issues found) File inclusion vulnerabilities occur when the path of the included file is controlled by unvalidated user input. If an attacker can somehow reference malicious files to be included in a script, it effectively has control over what the server executes. This includes database access, where all data is stored and user credentials and permissions are registered, effectlivey compromising the server completely. This includes all requirements regarding Access Control and Data Protection.
It is primarily an input validation issue though. |
| Dynamic Code Evaluation: Code Injection | (7 issues found) When code can be injected, this can be used to run code within another execution context than the user's execution context. As such, it can be used to circumvent Access Control in the application, and gain access to protected data.
Fortify can help pinpoint the locations that may expose a vulnerability. Example issues: - Fortify reports: "The file media.php interprets unvalidated user input as source code on line 2001. Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code." This issue is about the following code:
It is assumed that the "$start" variable is always a numeric value as a result of the operation on line 1998. I am not sure whether this is a valid assumption. Needs either further investigation, or an explicity type conversion. It is primarily an input validation issue though. |
| Header Manipulation (:Cookies) | (131 issues found) The issues that Fortify reports in this category, are related to including unvalidated data in an HTTP response header.
As such, this is primarily an input validation issue. |
| Hidden Field | (145 issues found) When a form contains hidden fields, an application still has the responsibility to validate this data as data coming from a potentially dangerous source location. A user can have full control over the value of a hidden field as it is sent to the server. Hidden fields relate to access control only when the contents of hidden fields are used for authorizing the request, without validating the contents of the value. It doesn't look like this is the case for Wordpress.
Because hidden fields are not shown, that doesn't mean that the contents are secret. In Wordpress, the hidden fields are not used for carrying sensitive data, so there are no Data Protection issues from the Hidden Fields that are reported by Fortify. |
| Insecure Randomness | (33 issues found) Fortify reports the cases where the provided mt_rand() or rand() functions are used, and warns that they should not be used when randomness must be guaranteed, i.e. as source of cryptographic operations. This could potentially have implications on Access Control (for example when random generated session id's can be predictable, they could be hijacked).
Wordpress specific: It doesn't look like Wordpress generates its own session id's, so there is no specific vulnerability there. Instead, many case of rand() use are for the scheduling of tasks (5% of the requests should include some maintenance, etc.). These cases do not directly expose security vulnerabilities when randomness is not pure random. There seems to be a custom wp_rand() function that generates a random value with a (host-configurable) seed value, that also rotates. It is strange that, despite the existence of a function like this, many functions still use rand() and mt_rand() as main source of randomness. |
| JavaScript Hijacking: Ad Hoc Ajax | (1 issue found) This could relate to Data Protection issues, as this warning is about possible sensitive data being exposed through an Ajax-style call from a JavaScript function.
Example Issue:
"Applications that use JavaScript notation to transport sensitive data can be vulnerable to JavaScript hijacking, which allows an unauthorized attacker to read confidential data from a vulnerable application." It is found in template.php:1573.
Doublechecking where ajaxurl comes from:
When looking at these lines, there is no sensitive data exposed to the URL that is being requested (just a timestamp). Also, the URL is set to a particular endpoint within the Wordpress deployment. Although this is being executed by the client (and as such the server should not trust it), when the URL is not built correctly, the implications are that an optimization is not used (compression would not be supported). |
| JavaScript Hijacking: Vulnerable Framework | (9 issues found) The type of issues in the Vulnerable Framework category are related to the data that is transmitted. As such it is related to Data Protection, to verify that no sensitive data is exposed.
Some of the reported issues are candidate for further investigation, as they are referencing URL's on remote servers. Others are disputable, as Fortify tries to make a point about lines of code for which not a lot is seen. Maybe the JavaScript analysis has some room for improvement. Example issue: In akismet.js:124 : "Applications that use JavaScript notation to transport sensitive data can be vulnerable to JavaScript hijacking, which allows an unauthorized attacker to read confidential data from a vulnerable application." The reported line points to the following code segment:
A call is being made to http(s)://s0.wordpress.com/mshots/v1/--something. This actually sends information about the fact that a user is visiting a particular blog to an external server. This may be considered sensitive data in certain conditions. |
| Log Forging | (38 issues found) Writing unvalidated user input to log files could allow an attacker to forge log entries or inject malicious content into the logs (possible V9). In our case, user does not submit any input which can be used to successfully forge logs, so it's not a problem. In case user could input a value which could possibly allow log forging, encoding exploitable characters such as "\r\n" can help prevent that. |
| Often Misused: File Upload | (5 issues found) Permitting users to upload files can allow attackers to inject dangerous content or malicious code to run on the server. An <input> tag of type file indicates the program accepts file uploads, thus possible V4 or V9 breach. |
| Open Redirect | (68 issues found) An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks thus has no implications on V4 or V9. |
| Password Management: Empty Password | (11 issues found) Empty passwords can compromise system security in a way that cannot be easily remedied, hence possible V4 breach. |
| Password Management: Hardcoded Password | (6 issues found) Hardcoded passwords may compromise system security in a way that cannot be easily remedied. In this case function just displays a login form:
<?php wp_login_form(); ?> so no impact on V4 or V9. |
| Password Management: Password in Comment | (154 issues found) Storing passwords or password details in plaintext anywhere in the system or system code can compromise system security in a way that cannot be easily remedied. Fortify gives this warning everytime it sees word "password" somewhere in the comments and thus assumes real password may be hardcoded nearby, but that's not the case anywhere in the code. |
| Path Manipulation | (53 issues found) Allowing user input to control paths used in filesystem operations could enable an attacker to access or modify otherwise protected system resources. In this case, the attacker can specify the value that enters the program at mysql_query() in wp-db.php at line 1213, and this value is used to access a filesystem resource at file_get_contents() in class-wp-editor.php at line 254. This may lead to V4 or V9 breach. |
| Possible Variable Overwrite: Global Scope | (88 issues found) Uses PHP function extract to expand an array. Could be abused for V4 to overwrite sessionId if an user supplied array is extracted inside a function for ACL. It could also be used to get data from the system (V9) to overwrite SQL queries etc. |
| Privacy Violation | (22 issues found) When private information inside the program gets written to an external location (console, file system or network). V4 could not be abused because there is noting written to the system, its just output. So V9 could be abused because of a miss configuration. But these errors are easily fixed. |
| SQL Injection | (16 issues found) Data from other parts of the program is used to construct a dynamic SQL query. This could be used for V4 or for V9. It some one makes it possible to do a sql injection you can do almost everything with the database (read,write,delete,execute) (depending on server settings). Its good to note that there is only one place where these query is executed but 16 places from where its called. |
| System Information Leak: External | (120 issues found) It occurs when system data or debugging information leaves the program to a remote machine via a socket or network connection. This is a list of all function output that is outputted
As far as I know the risks for V9 is almost nil but perhaps its returning information to the outside world that should not be done. And for V4 its kind of the same. I also know that Wordpress protects most of this stuff behind admin. So the information is hard to get. However the information is mostly returned to the website so if some part is not protected and some one is able to |
| System Information Leak: Internal | (15 issues found) Almost the same as "External" but its now sent to a local file, console or screen via printing or logging. I could only find calls to logging system. And the logs are protected behind Wordpress admin and inside the server, so as long as server ssh/file access is not attained and wordpress admin is not breached then it can have no impact on V4 or V9. |
| Weak Cryptographic Hash | (96 issues found) There is a lot of hashing going on, but they always use md5 or sha1. These are all easily crackable to this could potentially lead to V9 or V4 breach. (Erik: Attacks on MD5 have been attack on collision resistance; depending on the use of the hash collision resistance may be a problem or not; eg attacks on collision resistence do not have any impact on say hashing passwords . Btw, SHA1 is not that easy to crack, I think.) |
| Weak Encryption | (3 issues found) There are only two function that use "encryption", Namely hashPassword and CheckPassword. Its wrongly identified these because crypt returns a hash with salt and how its currently implemented is plenty strong. |
RATS
As we said in our reflection about RATS its just a glorified find tool that searches for well known dangerous functions.
The current database of RATS has these functions listed as dangerous:
mail, getallheaders, bzread, fgets, fgetss, getenv, file, fscanf, gzfile, gzgetc, gzgets, gzread, gzgetss, read, gzopen, eval, highlight_file, show_source, leak, chroot, fsockopen, pfsockopen, posix_getlogin, posix_ttyname, system, passthru, fopen, bzopen, popen, posix_mkfifo, opendir, exec, basename, chmod, chown, dirname, link, mkdir, readfile, rename, rmdir, symlink, unlink, filegroup, fileowner, fileperms, is_dir, is_executable, is_file, is_link, is_readable, is_writable, is_writeable, stat, lstat
While its most certainly true that these function can be dangerous and we will check for such function inside Wordpress (random samples) but as far as I know everything that RATS check is also checked by Fortify. (Erik: So did RATS produce a subset of warnings that Fortify gave? Or a superset? Maybe RATS gives a much more manageable number of warnings than Fortify? Some indication of the number would have been nice.)
Conclusion
V4 (Access Control Verification Requirements) and V9 (Data Protection Verification Requirements) and most verification steps are more complex then just simple function scanning. While good scanners will give some pointers on where and what to check, it's better to first map the general data flow and control flows in the application. Then it's more clear what that data flow means and what it can and can not (should not) do. For all different data flaws code needs to be checked and examined for possible vulnerabilities.
Fortify gives some useful pointers to look at and then backtrack a bit higher to figure out what more happens with the data. Because RATS and Fortify give issues based on function calls(Erik:This sentence does not make grammatical sense, so not clear what you're trying to say). Fortify does keep track on the data and if its already sanitized but still it is not perfect.
