arachni 0.4.6 → 0.4.7

checksums.yaml

@@ -1,15 +1,15 @@
 ---
 !binary "U0hBMQ==":
   metadata.gz: !binary |-
-    MjQyMTU0MWMwYTcyZTVhMjk0NDM0YjZlMmZiMDllYmI4ZTNkZjM4Zg==
+    ZDliMzg1ZDM5Zjc3YjU2Njg5NmY0MDVmY2I5ZmYwYzNmNmIwMTRhZA==
   data.tar.gz: !binary |-
-    MWI4ZjZmNzE5MzMxM2UyOTdkMzI4NjM0YTI0NWQwZDg4NmUxMzcwYw==
+    ZGExNDM4ZjUyMzhhOTY2MTEyODY4MThjMjQ0MDE0Njg2MTBkNTY1Yw==
 SHA512:
   metadata.gz: !binary |-
-    N2NkYzk3M2Y1MzY3YWQ0ZmEwZTM0ODBiZGUwNmZhYmIxOWRlODAyZDFjOTgw
-    YTIwMmQ0YjdhNDhjMWUzNWVkYzQ0MTM0ZjA5ZGQyYzM2MzQ2MDgyZWFiZmQw
-    MDY5NDFiMWY0ZGY4YzNjMWZjNTliMmFlM2YyZGM2MzFlZjY4YTg=
+    MzMyMzU2Yjg3ZjY3ZmVhZmU4ODViN2NjMTE2NDRhZjdiNTBhN2VhYTdlMWEx
+    MjE5ZmFkNjIzNjNmYWVkOWZmMzI1ZDBhOWFlYjY4NmFjNmVmNmI2NmZhYzE3
+    MTAwZDhjMDFjYmE5YWJhYmE5YzZjOTA5ZGJmM2Q3MzEzZTYzMGQ=
   data.tar.gz: !binary |-
-    M2JlNDdkN2MxODRhMThkYzQxNTBkZjcyMWQxNTg3ZWM2YzU5NTQyOTRhNmFm
-    ZTVkNzA4MjJjNmI2NzQ0ZTE2ZjNkNzgzNmFlMGJkYWQwMGRhNjc0M2RiODM5
-    YjY3MGM1MGRiNWFmYjI0MTg2YjVmNjZjYzhiOGZhNTk3NGM4YTE=
+    ZTA0ZWFhNDE2Mjk2ODcwNjk0MWEyNjMyZGI3NGRmMTQyOGMxYTJkMzUwZDFj
+    Y2NlMzlmODNjNzdkNWJiODU0ZTllZjRmODQ1MjQ2Y2Y0ZTAwYzIxOGI2YjRj
+    ZTVlNDU4MGViZjY5ODU1ZmZlOTg0MzQyOTg4NDNmOGIwNjI0ZDY=

data/CHANGELOG.md

@@ -1,5 +1,26 @@
 # ChangeLog
 
+## 0.4.7 _(April 12, 2014)_
+
+- `Spider`
+    - Fixed mixed up status messages upon out-of-scope redirections.
+- `HTTP`
+    - `disable_ssl_host_verification` set to `true`.
+- `Element`
+    - `Capabilities::Auditable::Taint`
+        - Fixed bug when checking for trust level of issue when there's no match.
+    - `Form`
+        - Updated to handle empty base-href values.
+- Plugins
+    - `autologin`
+        - Updated to handle stacked post-login redirects.
+        - Added debugging information for failed logins.
+    - `proxy`
+        - Fixed forwarding of request bodies.
+- Modules
+    - All
+        - Updated descriptions and remedies.
+
 ## 0.4.6 _(January 1, 2014)_
 
 - CLI user interfaces

data/Gemfile

@@ -1,4 +1,4 @@
-source 'http://rubygems.org'
+source 'https://rubygems.org'
 
 gem 'yard'
 gem 'redcarpet'

data/README.md

@@ -3,7 +3,7 @@
 <table>
     <tr>
         <th>Version</th>
-        <td>0.4.6</td>
+        <td>0.4.7</td>
     </tr>
     <tr>
         <th>Homepage</th>

data/lib/arachni/element/capabilities/auditable/taint.rb

@@ -216,6 +216,7 @@ module Auditable::Taint
             # Grab an untainted response.
             submit do |response|
                 @logged_issues.each do |issue|
+                    next if !issue.match
                     next if !response.body.include?( issue.match )
 
                     issue.verification = true

data/lib/arachni/element/form.rb

@@ -736,12 +736,10 @@ class Form < Arachni::Element::Base
     #
     def self.from_document( url, document )
         document = Nokogiri::HTML( document.to_s ) if !document.is_a?( Nokogiri::HTML::Document )
-        base_url = url
-        begin
-            base_url = document.search( '//base[@href]' )[0]['href']
-        rescue
-            base_url = url
-        end
+
+        base_url = document.search( '//base[@href]' )[0]['href'] rescue nil
+        base_url = url if base_url.to_s.empty?
+
         document.search( '//form' ).map do |cform|
             next if !(form = form_from_element( base_url, cform ))
             form.url = url

data/lib/arachni/http.rb

@@ -144,6 +144,7 @@ class HTTP
             follow_location:               false,
             max_redirects:                 opts.redirect_limit,
             disable_ssl_peer_verification: true,
+            disable_ssl_host_verification: true,
             timeout:                       opts.http_timeout || HTTP_TIMEOUT,
             username:                      opts.http_username,
             password:                      opts.http_password

data/lib/arachni/parser.rb

@@ -333,7 +333,7 @@ class Parser
                     exception_jail( false ){ self.class.extractors[name].new.run( doc ) }
                 end.flatten.uniq.compact.
                 map { |path| to_absolute( path ) }.compact.uniq.
-                reject { |path| skip?( path ) }
+                reject { |path| path.to_s.empty? || skip?( path ) }
         rescue ::Exception => e
             print_error e.to_s
             print_error_backtrace e

data/lib/arachni/spider.rb

@@ -417,8 +417,20 @@ class Spider
             if res.redirection? && res.location
                 @redirects << res.request.url
                 location = to_absolute( res.location, res.request.url )
-                if hit_redirect_limit? || skip?( location )
-                    print_info "Redirect limit reached, skipping: #{location}"
+
+                skipped     = false
+                redir_limit = false
+
+                if (redir_limit = hit_redirect_limit?) || (skipped = skip?( location ))
+
+                    if skipped
+                        print_info "Ignoring redirection due to exclusion criteria: #{location}"
+                    end
+
+                    if redir_limit
+                        print_info "Redirect limit reached, skipping: #{location}"
+                    end
+
                     decrease_pending
                     next
                 end

data/lib/version

@@ -1 +1 @@
-0.4.6
+0.4.7

data/modules/audit/code_injection.rb

@@ -14,14 +14,13 @@
     limitations under the License.
 =end
 
-#
 # It's designed to work with PHP, Perl, Python, Java, ASP and Ruby
 # but still needs some more testing.
 #
 #
 # @author Tasos "Zapotek" Laskos <tasos.laskos@gmail.com>
 #
-# @version 0.2
+# @version 0.2.1
 #
 # @see http://cwe.mitre.org/data/definitions/94.html
 # @see http://php.net/manual/en/function.eval.php
@@ -29,7 +28,6 @@
 # @see http://docs.python.org/py3k/library/functions.html#eval
 # @see http://www.aspdev.org/asp/asp-eval-execute/
 # @see http://en.wikipedia.org/wiki/Eval#Ruby
-#
 class Arachni::Modules::CodeInjection < Arachni::Module::Base
 
     def self.rand1
@@ -81,7 +79,7 @@ class Arachni::Modules::CodeInjection < Arachni::Module::Base
                 was successful.},
             elements:    [ Element::FORM, Element::LINK, Element::COOKIE, Element::HEADER ],
             author:      'Tasos "Zapotek" Laskos <tasos.laskos@gmail.com>',
-            version:     '0.2',
+            version:     '0.2.1',
             references:  {
                 'PHP'    => 'http://php.net/manual/en/function.eval.php',
                 'Perl'   => 'http://perldoc.perl.org/functions/eval.html',
@@ -91,16 +89,44 @@ class Arachni::Modules::CodeInjection < Arachni::Module::Base
             targets:     %w(PHP Perl Python ASP),
             issue:       {
                 name:            %q{Code injection},
-                description:     %q{Arbitrary code can be injected into the web application
-    which is then executed as part of the system.},
+                description:     %q{A modern web application will be reliant on 
+                    several different programming languages. These languages can 
+                    be broken up into two flavours. These are client side 
+                    languages such as those that run in the browser eg. 
+                    JavaScript and HTML, and server side languages that are 
+                    executed by the server (ASP, PHP, JSP, etc) to form the 
+                    dynamic pages (client side code) that are then sent to the 
+                    client. Because all server side code should be executed by 
+                    the server, it should only ever come from a trusted source. 
+                    Code injection occurs when the server takes untrusted server 
+                    side code (ie. From the client) and executes the code as if 
+                    it were on the server. Cyber-criminals will abuse this 
+                    weakness to execute their own arbitrary code on the server, 
+                    and could result in complete compromise of the server. 
+                    Arachni was able to inject specific server side code and 
+                    have the executed output from the code contained within the 
+                    server response. This indicates that proper input 
+                    sanitisation is not occurring.},
                 tags:            %w(code injection regexp),
                 cwe:             '94',
                 severity:        Severity::HIGH,
                 cvssv2:          '7.5',
-                remedy_guidance: %q{User inputs must be validated and filtered
-    before being evaluated as executable code.
-    Better yet, the web application should stop evaluating user
-    inputs as any part of dynamic code altogether.},
+                remedy_guidance: %q{ It is recommended that untrusted or 
+                    invalidated data is never stored where it may then be 
+                    executed as server side code. To validate data, the 
+                    application should ensure that the supplied value contains 
+                    only the characters that are required to perform the 
+                    required action. For example, where a username is required, 
+                    then no non-alpha characters should be accepted. 
+                    Additionally, within PHP, the "eval" and "preg_replace" 
+                    functions should be avoided as these functions can easily be 
+                    used to execute untrusted data. If these functions are used 
+                    within the application then these parts should be rewritten. 
+                    The exact way to rewrite the code depends on what the code 
+                    in question does, so there is no general pattern for doing 
+                    so. Once the code has been rewritten the eval() function 
+                    should be disabled. This can be achieved by adding eval to 
+                    disable_funcions within the php.ini file.},
                 remedy_code:     '',
                 metasploitable:  'unix/webapp/arachni_php_eval'
             }

data/modules/audit/code_injection_php_input_wrapper.rb

@@ -18,7 +18,7 @@
 #
 # @author Tasos "Zapotek" Laskos <tasos.laskos@gmail.com>
 #
-# @version 0.1
+# @version 0.2
 class Arachni::Modules::CodeExecutionPHPInputWrapper < Arachni::Module::Base
 
     def self.options
@@ -56,18 +56,51 @@ class Arachni::Modules::CodeExecutionPHPInputWrapper < Arachni::Module::Base
                 uses the php://input wrapper to try and load it.},
             elements:    [ Element::FORM, Element::LINK, Element::COOKIE, Element::HEADER ],
             author:      'Tasos "Zapotek" Laskos <tasos.laskos@gmail.com> ',
-            version:     '0.1',
+            version:     '0.2',
             references:  {
                 'OWASP'     => 'https://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution'
             },
             targets:     %w(PHP),
             issue:       {
                 name:            %q{Code injection (php://input wrapper)},
-                description:     %q{The web application can be forced to execute
-                    arbitrary code via the php://input wrapper.},
+                description:     %q{A modern web application will be reliant on 
+                    several different programming languages. These languages can 
+                    be broken up into two flavours. These are client side 
+                    languages such as those that run in the browser eg. 
+                    JavaScript and HTML, and server side languages that are 
+                    executed by the server (ASP, PHP, JSP, etc) to form the 
+                    dynamic pages (client side code) that are then sent to the 
+                    client. Because all server side code should be executed by 
+                    the server, it should only ever come from a trusted source. 
+                    Code injection occurs when the server takes untrusted server 
+                    side code (ie. From the client) and executes the code as if 
+                    it were on the server. Cyber-criminals will abuse this 
+                    weakness to execute their own arbitrary code on the server, 
+                    and could result in complete compromise of the server. 
+                    Arachni was able to inject specific server side code wrapped 
+                    within a php wrapper (<?php ... ?>) and have the executed 
+                    output from the code contained within the server response. 
+                    This indicates that proper input sanitisation is not 
+                    occurring..},
                 tags:            %w(remote injection php code execution),
                 cwe:             '94',
-                severity:        Severity::HIGH
+                severity:        Severity::HIGH,
+                remedy_guidance: %q{It is recommended that untrusted or 
+                    invalidated data is never stored where it may then be 
+                    executed as server side code. To validate data, the 
+                    application should ensure that the supplied value contains 
+                    nly the characters that are required to perform the required 
+                    action. For example, where a username is required, then no 
+                    non-alpha characters should be accepted. Additionally, 
+                    within PHP, the "eval" and "preg_replace" functions should 
+                    be avoided as these functions can easily be used to execute 
+                    untrusted data. If these functions are used within the 
+                    application then these parts should be rewritten. The exact 
+                    way to rewrite the code depends on what the code in question 
+                    does, so there is no general pattern for doing so. Once the 
+                    code has been rewritten the eval() function should be 
+                    disabled. This can be achieved by adding eval to 
+                    disable_funcions within the php.ini file.},
             }
 
         }

data/modules/audit/code_injection_timing.rb

@@ -23,7 +23,7 @@
 #
 # @author Tasos "Zapotek" Laskos <tasos.laskos@gmail.com>
 #
-# @version 0.3
+# @version 0.4
 #
 # @see http://cwe.mitre.org/data/definitions/94.html
 # @see http://php.net/manual/en/function.eval.php
@@ -62,7 +62,7 @@ class Arachni::Modules::CodeInjectionTiming < Arachni::Module::Base
                 was successful using a time delay.},
             elements:    [ Element::FORM, Element::LINK, Element::COOKIE, Element::HEADER ],
             author:      'Tasos "Zapotek" Laskos <tasos.laskos@gmail.com>',
-            version:     '0.3',
+            version:     '0.4',
             references:  {
                 'PHP'    => 'http://php.net/manual/en/function.eval.php',
                 'Perl'   => 'http://perldoc.perl.org/functions/eval.html',
@@ -74,21 +74,44 @@ class Arachni::Modules::CodeInjectionTiming < Arachni::Module::Base
 
             issue:       {
                 name:            %q{Code injection (timing attack)},
-                description:     %q{Arbitrary code can be injected into the web application
-    which is then executed as part of the system.
-    (This issue was discovered using a timing attack; timing attacks
-    can result in false positives in cases where the server takes
-    an abnormally long time to respond.
-    Either case, these issues will require further investigation
-    even if they are false positives.)},
+                description:     %q{A modern web application will be reliant on 
+                    several different programming languages. These languages can 
+                    be broken up into two flavours. These are client side 
+                    languages such as those that run in the browser eg. 
+                    JavaScript and HTML, and server side languages that are 
+                    executed by the server (ASP, PHP, JSP, etc) to form the 
+                    dynamic pages (client side code) that are then sent to the 
+                    client. Because all server side code should be executed by 
+                    the server, it should only ever come from a trusted source. 
+                    Code injection occurs when the server takes untrusted server 
+                    side code (ie. From the client) and executes the code as if 
+                    it were on the server. Cyber-criminals will abuse this 
+                    weakness to execute their own arbitrary code on the server, 
+                    and could result in complete compromise of the server. By 
+                    injecting server side code that is known to take a specific 
+                    amount of time to execute Arachni was able to detect time 
+                    based code injection. This indicates that proper input 
+                    sanitisation is not occurring.},
                 tags:            %w(code injection timing blind),
                 cwe:             '94',
                 severity:        Severity::HIGH,
                 cvssv2:          '7.5',
-                remedy_guidance: %q{User inputs must be validated and filtered
-    before being evaluated as executable code.
-    Better yet, the web application should stop evaluating user
-    inputs as any part of dynamic code altogether.},
+                remedy_guidance: %q{It is recommended that untrusted or 
+                    invalidated data is never stored where it may then be 
+                    executed as server side code. To validate data, the 
+                    application should ensure that the supplied value contains 
+                    nly the characters that are required to perform the required 
+                    action. For example, where a username is required, then no 
+                    non-alpha characters should be accepted. Additionally, 
+                    within PHP, the "eval" and "preg_replace" functions should 
+                    be avoided as these functions can easily be used to execute 
+                    untrusted data. If these functions are used within the 
+                    application then these parts should be rewritten. The exact 
+                    way to rewrite the code depends on what the code in question 
+                    does, so there is no general pattern for doing so. Once the 
+                    code has been rewritten the eval() function should be 
+                    disabled. This can be achieved by adding eval to 
+                    disable_funcions within the php.ini file.},
                 remedy_code:     '',
                 metasploitable:  'unix/webapp/arachni_php_eval'
             }

data/modules/audit/csrf.rb

@@ -42,7 +42,7 @@
 #
 # @author Tasos "Zapotek" Laskos <tasos.laskos@gmail.com>
 #
-# @version 0.3.1
+# @version 0.3.2
 #
 # @see http://en.wikipedia.org/wiki/Cross-site_request_forgery
 # @see http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
@@ -167,27 +167,57 @@ class Arachni::Modules::CSRF < Arachni::Module::Base
                 It requires a logged-in user's cookie-jar.},
             elements:    [ Element::FORM ],
             author:      'Tasos "Zapotek" Laskos <tasos.laskos@gmail.com> ',
-            version:     '0.3.1',
+            version:     '0.3.2',
             references:  {
                 'Wikipedia'    => 'http://en.wikipedia.org/wiki/Cross-site_request_forgery',
                 'OWASP'        => 'http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)',
-                'CGI Security' => 'http://www.cgisecurity.com/csrf-faq.html'
+                'CGI Security' => 'http://www.cgisecurity.com/csrf-faq.html',
+                'WASC'         => 'http://projects.webappsec.org/w/page/13246919/Cross%20Site%20Request%20Forgery'
             },
             targets:     %w(Generic),
 
             issue:       {
                 name:            %q{Cross-Site Request Forgery},
-                description:     %q{The web application does not, or can not,
-     sufficiently verify whether a well-formed, valid, consistent
-     request was intentionally provided by the user who submitted the request.
-     This is due to a lack of secure anti-CSRF tokens to verify
-     the freshness of the submitted data.},
+                description:     %q{In the majority of today's web applications, 
+                    clients are required to submit forms. When these forms are 
+                    submitted that contents within the form are typically 
+                    processed by the server. An example of such a form is when 
+                    an administrator wishes to create a new user for the 
+                    application. In the simplest form the administrator would 
+                    submit a form with the users Name, Password, and Role (level 
+                    of access). Cross Site Request Forgery (CSRF) is where an 
+                    administrator could be tricked into clicking on a link that 
+                    if logged into the application would automatically submit 
+                    the form without any further interaction. Cyber-criminals 
+                    will look for sites where sensitive functions are performed 
+                    in this vulnerable manner, and then craft malicious requests 
+                    that will be used against clients in a social engineering 
+                    attack. There are 3 things that are required for a CSRF 
+                    attack to occur. 1. The form must perform a sensitive action 
+                    2. The victim (admin the example above) must have an active 
+                    session 3. Most importantly, all parameter values must be 
+                    known or guessable. Arachni discovered that all parameters 
+                    within the form were known or predictable, and therefore 
+                    could be vulnerable to CSRF. Manual verification may be 
+                    required to check whether the submission will then perform a 
+                    sensitive action such as reset a password, modify user 
+                    profiles, post content for a forum, etc.},
                 tags:            %w(csrf rdiff form token),
                 cwe:             '352',
                 severity:        Severity::HIGH,
-                remedy_guidance: %q{A unique token that guaranties freshness of submitted
-    data must be added to all web application elements that can affect
-    business logic.}
+                remedy_guidance: %q{Based on the risk determined by manual 
+                    verification of whether the submission will then perform a 
+                    sensitive action, it is recommended that the server utilise 
+                    CSRF tokens. These can be configured in such a way that each 
+                    session generates a new CSRF token or such that each 
+                    individual request requires a new token. CSRF tokens are 
+                    passed to the server as a normal parameter and not as a 
+                    cookie value. It is equally important that the server track 
+                    and maintain the status of each token, this will enable a 
+                    server to reject any request that does not contain a valid 
+                    token, and therefore prevent any cyber-criminal from knowing
+                    or guessing all parameter values. For examples of framework 
+                    specific remediation, refer to the references.}
             }
         }
     end

data/modules/audit/file_inclusion.rb

@@ -18,7 +18,7 @@
 #
 # @author Tasos "Zapotek" Laskos <tasos.laskos@gmail.com>
 #
-# @version 0.1.1
+# @version 0.1.2
 #
 # @see http://cwe.mitre.org/data/definitions/98.html
 # @see https://www.owasp.org/index.php/PHP_File_Inclusion
@@ -103,7 +103,7 @@ class Arachni::Modules::FileInclusion < Arachni::Module::Base
                 based on the presence of relevant content or errors in the HTTP responses.},
             elements:    [ Element::FORM, Element::LINK, Element::COOKIE, Element::HEADER ],
             author:      'Tasos "Zapotek" Laskos <tasos.laskos@gmail.com> ',
-            version:     '0.1.1',
+            version:     '0.1.2',
             references:  {
                 'OWASP' => 'https://www.owasp.org/index.php/PHP_File_Inclusion'
             },
@@ -111,13 +111,43 @@ class Arachni::Modules::FileInclusion < Arachni::Module::Base
 
             issue:       {
                 name:            %q{File Inclusion},
-                description:     %q{The web application enforces improper limitation
-                    of a pathname.},
+                description:     %q{Web applications occasionally use
+                    parameter values to store the location of a file required by
+                    the server. An example of this is often seen in error pages 
+                    where the actual file path for the error page is called the 
+                    parameter value. For example 
+                    'yoursite.com/error.php?page=404.php'. A file inclusion 
+                    occurs when the parameter value (ie. path to file being 
+                    called by the server) can be substituted with the path of 
+                    another resource on the same server, and the server then 
+                    displays that resource as text without processing it. 
+                    Therefore revealing the server side source code. Cyber-
+                    criminals will abuse this vulnerability to view restricted 
+                    files or the source code of various files on the server. 
+                    Arachni discovered that it was possible to substitute a 
+                    parameter value with another resource and have the server 
+                    return the contents of the resource to the client within 
+                    the response. },
                 tags:            %w(file inclusion error injection regexp),
                 cwe:             '98',
                 severity:        Severity::HIGH,
-                remedy_guidance: %q{User inputs must be validated and filtered
-                    before being used as a part of a filesystem path.}
+                remedy_guidance: %q{ It is recommended that untrusted or 
+                    invalidated data is never used to form a literal file 
+                    include request. To validate data, the application should 
+                    ensure that the supplied value for a file is permitted. This 
+                    can be achieved by performing whitelisting on the parameter 
+                    value. The whitelist should contain a list of pages that the 
+                    application is permitted to fetch resources from. If the 
+                    supplied value does not match any value in the whitelist 
+                    then the server should redirect to a standard error page. 
+                    In some scenarios where dynamic content is being requested 
+                    it may not be possible to perform validation of a list of 
+                    trusted resources, therefor the list must also become 
+                    dynamic (update as the files change), or perform filtering 
+                    to remove any unrequired user input such as semicolons or 
+                    periods etc. and only permit a-z0-9. It is also advised that 
+                    sensitive file are not stored within the web root, and that 
+                    the user permissions enforced by the directory are correct.}
             }
 
         }